How to create connected system for Active Directory?

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.