What is the best way to implement a 21 CFR Part 11 compliance?
This is a use case where a user needs to verify they are who they say they are when making a change. E.g. They update a record, click save, then we prompt them for their username and password. In this case the user is already logged in but in order to be 21 CFR Part 11 compliant we need to ask them again to ensure that the user requesting the change is actually the user logged in.
Would prompting an Okta widget control work in this case, or would cause token problems? What would be the best flow for this? Again this is assuming the user has already been authenticated by Okta, has a token and is actively working on the site, but we’re required to add this additional user verification when they do some sort of audit action.
My organization have exactly same requirement to meet the 21 CFR Part 11 for our application. I agree with @Govner, forceAuthn seems like the best thing I can choose to implement the requirement.
But I got into another problem, like @EricWilson said, user will redirect to OKTA to verify their username and password after they update the record and click the save button. After that, OKTA will redirect user to callback url (Single sign-on URL), my application receive the request but it doesn’t know user is signing to which record (context is lost).
My idea is set some custom fields when sending SAML to the idP and I’m hoping idP (OKTA) can return those custom fields to me once it done. Unfortunately, my solution is not working, seems like the SSO process is not working like that. How can I save the context so that I can know which record user is signing after OKTA verify the username and password?