Specify 7 Authentication ID linking Workflow Options - Which works better for you?

[beach53]

Specify 7 Setting Up Single Sign On (SSO)

Identity Linking Workflow Options

Specify Collections Consortium Members - we cordially invite your ideas and input on these two authentication ID linking workflow options for a forthcoming version of Specify 7. We will implement one option.

To extend Specify 7 to support SSO authentication via external identity providers it will be necessary to establish a workflow for associating external identities with new or existing Specify 7 user accounts that exist within a Specify database. We are considering two possible workflows for accomplishing this: Option 1: Start with Specify username and password pairs, or Option 2: use “invitation” links.

Option 1: Start with Specify usernames and passwords

1a. If a user account, available from an external Identity provider, has an existing Specify account:

1. The user logs into Specify 7 with an existing Specify user name and password.
2. The Sp7 server recognizes that the session is not authenticated.
3. The Sp7 server prompts the user to login via a configured external identity provider.
4. The user successfully authenticates to the external identity provider.
5. If the resulting external identity is already linked to a Specify user account, the user is immediately logged into that Specify account.
6. Otherwise, the user is prompted to enter their existing Specify username and password.
7. The username and password authentication succeeds for an existing Specify user account that is not currently linked to an external identity.
8. The user’s external identity is linked to that Specify user account, and the user is logged into that account.
9. Future logins by the user will be immediately logged in at step 5 since their external identity is now linked to a Specify account ID.
10. The user would no longer need to use the Specify username and password.

1b. If a user from an external identity provider does not have a Specify account:

1. A Specify 7 administrator creates and configures a new Specify user account.
2. The administrator assigns a temporary password to the account.
3. The temporary password and username are emailed or otherwise securely communicated to the intended user of the new account.
4. Workflow proceeds as above in 1a.

Option 2: Use invitation links

2a. If the user does not have an existing Specify account:

1. A Specify 7 administrator creates and configures a new Specify user account.
2. If the account is to be used with Specify 6, it would be assigned a temporary password at this time. Otherwise, no password needs to be assigned.
3. The administrator presses a button on the user account page to generate an “invite link” which embeds a cryptographic token with the new account id and other information.
4. The invite link is emailed or otherwise securely communicated to the intended user of the account.
5. The user opens the link and is presented with a welcome page which verifies the token and ensures it has not been previously used.
6. The user is prompted to login via a configured external identity provider.
7. The user successfully authenticates to the external identity provider.
8. The user’s external identity is linked to the Specify account ID in the token.
9. In the future the user can immediately log into the Specify account by authenticating with the external identity provider (steps 1 - 5 of the Option 1a workflow).

2b. If the user has an existing Specify account:

1. User begins at step 3 and goes to step 5 in the 1a workflow above.

[beach53]

We would be particularly interested in any security or other organizational policies or strategies that might impinge on this choice. Thx!

[foozleface]

Generally, I'd like to err on "less work for the administrator", which would seem to be option 1 (i.e.: no intervention required to move existing users to the new SSO accounts). Also, for option 1 if I'm lazy I don't have to ensure that I have a proper mailserver up and working.

Are there plans to link specify6 to SSO in any way? Right now the two products aren't at feature parity, so we can't get away from S6. If the user has to recall their S6 login, there's no benefit to SSO.

[mcruz-umich]

I vote for Option 1.
It is similar to how I manage our AEM [Adobe Experience Manager] platform.
However both options would work for me.
I agree with @foozleface that S6 and S7 not being at feature-parity is an issue since many of my users switch between S6 and S7 or rely only on S6. I do have several users that predominantly use S7 though, so for them, SSO would be a nice convenience.

Additional security issues:

1. As admin, I would want ways to force-expire user sessions. This could be useful after I deploy certain types of custom code updates.
2. Once a user has completed the workflow once and can now get into S7 with SSO and not their old credentials, I would like to make sure they are no longer able to get in using their old credentials. I am thinking I would not want them laying around as a possible vulnerability. What actions can the developers take to eliminate the ability to sign in to S7 with the old credentials after having completed a successful SSO login?

[FedorSteeman]

We'd welcome SSO authentication, but I'm getting the impression of the above that this would be enforced rather than being an extra option. For our institution, the SSO server in question would default to the university's, which we're not all that impressed by. Also, we service institutions outside of our university.

I'm a bit wary of enforcing SSO authentication for two reasons:

1. We don't want to put off end users with an elaborate log in process. A great deal of our end users are less tech savvy emeriti and some such and thus may get stuck at too many steps.
2. Most of our institutions falls outside of the university and we've had major problems getting the university security system to include staff members of these partner institutions.

The only advantage of using our university's SSO would be making Specify automatically add new users when they're already registered in that system. However, in both above options, there's still manually creation of accounts in Specify primarily.

Also: Both options seems to imply enforcing SSO authentication. If this enforcing can be turned off, then I would prefer option 1, because that implies that authentication is still controlled from Specify which stores the usernames and passwords, and can be defaulted to if the external SSO lets down.