Dear All, Can anyone please tell me how to create connected system for active directory, because there is no template for active directory in Appian.
Thanks in advance!
Discussion posts and replies are publicly visible
AFAIK the active directory does not provide a HTTP base API Appian could connect to. But what is your use case?
I have the requirement to create integration with AD to give uses functionality to provide uname and pwd to approve rows in interface.
We need to implement 21 CFR part 11 signatures while approving any records.
OK, but for electronic signatures to work, your user does not need to enter his credentials a second time. At least as far as I know.
Maybe you can give us a bit more insights into what you want to achieve.
Yes, the user wants to click on approve button in interface for that record item and it should be approved through SSO without entering uname and pwd.
OK. That is the standard of what we do in Appian. You assign a task "Approve something" to a person and that person clicks the approve button and the process continues.
Ok, but when user is approving the item, it should approve via SSO. How to connect appian with AD for such approvals.
The user has to login (SSO) to be able to open the task and click the button. Is this not good enough?
No that is not good enough. I know a bunch of Pharma companies use Appian. We are tasked to ALWAYS PROMPT for user name and password when an approval process is being executed. This is the standard called 21 CFR Part 11. Been around for years. Right now, we cannot use SSO for our appian application until we figure out how to connect to ACTIVE DIRECTORY to verify what the user enters for user name and password during the approval cycle is correct. We are currently doing this verification using local accounts.
Isn't there some other pharma company that has implemented 21 CRF Part 11 approvals using SSO?
victoriav0001 said:21 CFR Part 11
Can you specify exactly what this code says about the User Experience you envision, and what exactly you're expecting the resultant User Experience to actually be? Because while i'm not familiar with the FDA rule you've referenced, I know that Appian's currently-in-use authentication system passes muster enough for FEDRAMP and multiple US federal agencies - so I'd be at least a little surprised if it's insufficient here.
thanks for your help. And I agree, I have to think Appian can support what we want to do. I am NOT a developer. But I have been told that although appian supports SSO, it does not support SSO for a second level of authentication. From a UI standpoint, when the user is prompted for their approval, we display a user name and password field. They enter that information then click "authenticate" and the tool verifies the user name and password via local account verification at this time. Instead of local accounts, we want to go out and verify against the active directory username/password data.
Users must verify against their Active Directory accounts upon Appian login - this is a live AD verification and essentially must be done at least every workday at the beginning of their usage of Appian (and further SSO parameters are defined by the organization; for instance the timeout interval, etc). I don't see why this would be an insufficient level of verification.
Appian does not have a direct built-in way to force re-verification at arbitrary points in the system, whether that's specific tasks, reports, etc. At this point I'd suggest that whoever proposed this "requirement" is encroaching upon the ideological boundary where they're really "dictating design" rather than actually giving requirements.
That said - in the past I've seen a second-layer verification implemented (manually) by a project team whereupon certain high-level users self-choose a "PIN" that's stored in the DB, and then they're asked to enter their PIN for secondary verificaiton upon submission of certain tasks. The advantage here is you'd have UI-level / form-level control of this verification and the design thereof; the disadvantage (such as it is) would be that your design team would need to build and manage it manually.
Dear Mike, Thanks for your reply. I guess I am just very surprised that this isn't more common request. We have to do the two step authentication due to government regulations. We are currently implementing this with local accounts but the user base would prefer SSO and not "another" username/password they have to remember.
Why not just use an identity provider that support two-factor authentication. Integrate that using SAML and you can do any kind of fancy login mechanisms.
victoriav0001 were you able to figure this out?
These are GxP rules and some pharma companies interpret it in a way that the user needs to reauthenticate. I know, it's weird and actually quite dumb (it's actually increasing risk, not decreasing it), but it is the way it is. There is no connected system - in the past, the customer provided a common service that we would call against that in turn made LDAP queries. You can use a masked text field to pass the credentials into the call.
It's been a while since I did this and I think there was a function to call LDAP directly but I need to dig for it.
We did not pursue this due to resource constraints. So we are staying with local accounts. It is a bit frustrating to the users but that is how it goes. thank you for all the good feedback.