Instance Authentication Workflow Diagram Text Description

1. A user attempts to access a HealthShare user interface page on a client instance, which may be any instance in a HealthShare federation.

2. The client instance invokes the GetCredentials method in its ZAUTHENTICATE routine.

3. The client instance invokes the OnGetCredentials local callback. Local callbacks are in the class HS.Local.ZAUTHENTICATE.

   • In the standard workflow, OnGetCredentials does not set the credentials, so the local instance displays the user login page configured for the web application, and the user enters credentials.

   • Alternatively, OnGetCredentials can set the user credentials directly.

4. Once it acquires user credentials, the local instance invokes the Main method in its ZAUTHENTICATE routine.

5. The client instance invokes the OnZAUTHENTICATE local callback:

   • If OnZAUTHENTICATE sets the username and roles directly, then the client instance sets those values in a properties array. This is not the standard workflow. The next processing steps are described later in this workflow description where the client instance sets the username and roles in a properties array after the Registry performs authentication and authorization.

   • If OnZAUTHENTICATE does not directly set the username and roles, which is the standard workflow, then the client instance invokes the OnBeforeAA local callback.

6. The client instance redirects the authentication request to the HealthShare Registry by sending it an AuthenticateAuthorize message. The Registry handles authentication and then authorization of the user.

7. When it receives the AuthenticateAuthorize message, which indicates the domain, loginID, and password, the Registry invokes the OnAuthenticate callback in the security domain callback class. The security domain callback class is your custom class that extends HS.Registry.Person.User.HSAuth.

   • In an internal security domain, the HealthShare user/clinician registry validates the user's credentials.

   • In an external security domain, the OnAuthenticate callback designates an external source such as an LDAP server to validate the credentials.

8. Now that the credentials are validated, the Registry invokes the OnAuthorize callback in the security domain callback class:

   • In an internal security domain, the HealthShare user/clinician registry obtains roles for the login ID.

   • In an external security domain, the OnAuthorize callback designates an external source such as an LDAP server to obtain the roles, given the username and login ID.

9. The Registry returns the username and roles to the client instance in an AuthResponse message.

10. The client instance invokes the OnAfterAA local callback.

11. Now the client instance sets the username and roles in a properties array. Note that this step is where the earlier non-standard workflow left off.

12. The client instance invokes the OnAfterProperties local callback.

13. If two-factor authentication is not enabled, then the user is granted access to the user interface page and the workflow is complete.

14. If two-factor authentication is enabled, then the client instance invokes the SendTwoFactorToken method in its ZAUTHENTICATE routine.

15. The client instance invokes the OnSendTwoFactorToken local callback. This callback creates a new security token, and sends it to the mobile phone of the user.

16. The client instance prompts the user for the two-factor token.

17. The user enters the two-factor token.

18. InterSystems IRIS validates the two-factor token.

19. The user is granted access to the user interface page and the workflow is complete.