UX for SSO

Chris had a series of questions. I won't paste them in one big chunk, as the first one had a faulty premise. Instead, Chris can ask them one-by-one as comments, and we'll answer as comments.

The first one: "Will everyone use SSO?" No, affiliates will still do everything the way it is now.

Sorry for the slow uptake on this. I misread Paul's first comment and thought he would be asking all of the questions. I've gone ahead and updated the bug description to include my current understanding of what OSF needs from this feature. See above.

Just passing along the comment I received from Oleg when I passed along the revised description:

Nat, I think this is mostly correct. I’d like to see a KARL main login page changed to just ask for the username/email. Once submitted, the system can check if this user exists and what type of Auth they are enabled for. In the case of Okta/Google, they will be redirected via SP initiated SAML login requests to the IDP and proceed to login there. If the user is not SSO enabled, they would be asked to enter in a password (i.e. affiliates).

This would effectively mean that we are disabling passwords for SSO enabled users. It would also allow us to phase SSO in gradually.

Let me know if this makes sense.

-Oleg

Chris, to get you caught up on some things that have changed in the last six months…we did a lot of work in fall regarding login. The session cookie times are much shorter, there are things that don’t let you have more than one session at a time, etc. I believe this is a list:

  http://bit.ly/2kGl3dt

I don’t think any of them affect your work.

> On Feb 6, 2017, at 4:11 PM, Chris Rossi <email address hidden> wrote:
>
> Sorry for the slow uptake on this. I misread Paul's first comment and
> thought he would be asking all of the questions. I've gone ahead and
> updated the bug description to include my current understanding of what
> OSF needs from this feature. See above.
>
> ** Description changed:
>
> - Chris has started on the UX for the SSO work. We'll use this ticket as
> - an umbrella place to ask Nat questions and to make statements about
> - decisions.
> + Basic vision for UX surrounding new SAML based SSO feature:
> +
> + Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> + addresses. Users arriving via SSO will be mapped to their Karl profiles
> + via email address. This requires that email address be unique across
> + all users. Will need to write a script to run against production data
> + to verify this is true. A user who is authenticated via SSO must also
> + have a profile in Karl in order to have any access to the system.
> +
> + An unknown user will be taken to /login.html, as is current practice.
> + The SSO options will be added to the login screen. Visually, I'm not
> + sure how that should work. But since we don't know, a priori, if a user
> + is staff or an affiliate, the initial login screen will have to be able
> + to handle either.
> +
> + Configuration of SAML IdPs will be generic, with software written to be
> + able, theoretically, to handle any IdP. We just have to add appropriate
> + configuration server side. As far as the user experience, on the login
> + screen, each configured IdP will be displayed as an icon, and a line of
> + text, both of which come from configuration. To login using SSO, user
> + clicks one of these icons, authenticates, and is returned to Karl.
> +
> + Optionally, we can consider disabling password based authentication for
> + users that should be logging in via SSO.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to have any access
> to the system.
>
> An unknown user will be taken to /login.html, as is current practice.
> The SSO options will be added to the login screen. Visually, I'm not
> sure how that should ...

Nat,

Regarding Oleg's comment--while that certainly would work, it requires the SSO users to do more work than they otherwise would need to do--they're entering a username once for Karl, when all they would really need to do is just click on the SSO link. Then they'll need to enter a username for the SSO, so they end up entering it twice. It would work but it doesn't seem like the best user experience.

Hi Chris,

Yes, we definitely understand that the proposed workflow will require some users to enter their username more than once. What we like, however, is that it gives us more time roll out SSO in a gradual way, without exposing direct links that may confuse users that have yet to be rolled into SSO.

Thanks,
Nat

Ok, this opens up a whole new line of questioning then. How do we decide which authentication scheme to use for a particular user? Is there a rule that can be applied? Do we just need to make it configurable per user?

I guess I was assuming that KARL would have a table that tracks the authentication method for each user. That's usually the workflow with other apps. For example, if I want to log into Box directly from Box (instead of from OKTA), I would select, Use SSO, then enter my email address and then Box redirects me to the correct provider based on my account settings.

Unfortunately, there won't be a single standard for why certain staff have OKTA and why others have Google. For the most part, staff with Entity Open Society Institute will use OKTA, while staff with other entities will use Google, but that isn't always the case. There are a fair number of edge case staff who sit in national foundations, but have full access to OKTA. So we need to build in a some way to accommodate those edge cases.

-Nat

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Chris Rossi
Sent: Tuesday, February 7, 2017 1:24 PM
To: Nathaniel Katin-Borland <email address hidden>
Subject: [Bug 1662250] Re: UX for SSO

Ok, this opens up a whole new line of questioning then. How do we decide which authentication scheme to use for a particular user? Is there a rule that can be applied? Do we just need to make it configurable per user?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1662250

Title:
  UX for SSO

Status in KARL4:
  New

Bug description:
  Basic vision for UX surrounding new SAML based SSO feature:

  Identity Providers (IdPs, e.g. Okta, Google) will be providing email
  addresses. Users arriving via SSO will be mapped to their Karl
  profiles via email address. This requires that email address be
  unique across all users. Will need to write a script to run against
  production data to verify this is true. A user who is authenticated
  via SSO must also have a profile in Karl in order to have any access
  to the system.

  An unknown user will be taken to /login.html, as is current practice.
  The SSO options will be added to the login screen. Visually, I'm not
  sure how that should work. But since we don't know, a priori, if a
  user is staff or an affiliate, the initial login screen will have to
  be able to handle either.

  Configuration of SAML IdPs will be generic, with software written to
  be able, theoretically, to handle any IdP. We just have to add
  appropriate configuration server side. As far as the user
  experience, on the login screen, each configured IdP will be displayed
  as an icon, and a line of text, both of which come from configuration.
  To login using SSO, user clicks one of these icons, authenticates, and
  is returned to Karl.

  Optionally, we can consider disabling password based authentication
  for users that should be logging in via SSO.

To manage notifications about this bug go to:
https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions

I guess I was assuming that KARL would have a table that tracks the authentication method for each user. That's usually the workflow with other apps. For example, if I want to log into Box directly from Box (instead of from OKTA), I would select, Use SSO, then enter my email address and then Box redirects me to the correct provider based on my account settings.

Unfortunately, there won't be a single standard for why certain staff have OKTA and why others have Google. For the most part, staff with Entity Open Society Institute will use OKTA, while staff with other entities will use Google, but that isn't always the case. There are a fair number of edge case staff who sit in national foundations, but have full access to OKTA. So we need to build in a some way to accommodate those edge cases.

-Nat

Ok. Help me remember. Some users are synced from a data source that OSF has, and other users live exclusively in the Karl database? Is that right?

I would have expected OSF to manage this mapping in GSA. We’d then reflect the setting (which IdP) onto the profile. At the moment, the decision of KarlStaff, for example, and many other groups comes from GSA.

—Paul

> On Feb 7, 2017, at 5:25 PM, Nat Katin-Borland <email address hidden> wrote:
>
> I guess I was assuming that KARL would have a table that tracks the
> authentication method for each user. That's usually the workflow with
> other apps. For example, if I want to log into Box directly from Box
> (instead of from OKTA), I would select, Use SSO, then enter my email
> address and then Box redirects me to the correct provider based on my
> account settings.
>
> Unfortunately, there won't be a single standard for why certain staff
> have OKTA and why others have Google. For the most part, staff with
> Entity Open Society Institute will use OKTA, while staff with other
> entities will use Google, but that isn't always the case. There are a
> fair number of edge case staff who sit in national foundations, but have
> full access to OKTA. So we need to build in a some way to accommodate
> those edge cases.
>
> -Nat
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Chris Rossi
> Sent: Tuesday, February 7, 2017 1:24 PM
> To: Nathaniel Katin-Borland <email address hidden>
> Subject: [Bug 1662250] Re: UX for SSO
>
> Ok, this opens up a whole new line of questioning then. How do we
> decide which authentication scheme to use for a particular user? Is
> there a rule that can be applied? Do we just need to make it
> configurable per user?
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to have any access
> to the system.
>
> An unknown user will be taken to /login.html, as is current practice.
> The SSO options will be added to the login screen. Visually, I'm not
> sure how that should work. But since we don't know, a priori, if a
> user is staff or an affiliate, the initial login screen will have to
> be able to handle either.
>
> Configuration of SAML IdPs will be generic, with software written to
> be able, theoretically, to handle any IdP. We just have to add
> appropriate configuration server side. As far as the user
> experience, on the login screen, each configured IdP will be displayed
> as an icon, and a line of text, both of which come from configuration.
> To login using SSO, user clicks one of these icons, authenticates, and
> is returned to Karl.
>
> Optionally, we ...

And all users come from GSA?

All users who will get SSO, come from GSA.

—Paul

> On Feb 7, 2017, at 7:38 PM, Chris Rossi <email address hidden> wrote:
>
> And all users come from GSA?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to have any access
> to the system.
>
> An unknown user will be taken to /login.html, as is current practice.
> The SSO options will be added to the login screen. Visually, I'm not
> sure how that should work. But since we don't know, a priori, if a
> user is staff or an affiliate, the initial login screen will have to
> be able to handle either.
>
> Configuration of SAML IdPs will be generic, with software written to
> be able, theoretically, to handle any IdP. We just have to add
> appropriate configuration server side. As far as the user
> experience, on the login screen, each configured IdP will be displayed
> as an icon, and a line of text, both of which come from configuration.
> To login using SSO, user clicks one of these icons, authenticates, and
> is returned to Karl.
>
> Optionally, we can consider disabling password based authentication
> for users that should be logging in via SSO.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions

Yes, that's correct all staff users come from GSA. If you think that we need to add a field in GSA that contains the SSO provider for that user, then let me know so that I can loop Ajo into the conversation.

Thanks,
Nat

You can have us make a UI for managing the SSO provider for staff. But in the past, we’ve relied on GSA for that kind of information about staff users (IMO).

It’s your call…either Ajo provides the UI or we do.

—Paul

> On Feb 8, 2017, at 9:42 AM, Nat Katin-Borland <email address hidden> wrote:
>
> Yes, that's correct all staff users come from GSA. If you think that we
> need to add a field in GSA that contains the SSO provider for that user,
> then let me know so that I can loop Ajo into the conversation.
>
> Thanks,
> Nat
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to have any access
> to the system.
>
> An unknown user will be taken to /login.html, as is current practice.
> The SSO options will be added to the login screen. Visually, I'm not
> sure how that should work. But since we don't know, a priori, if a
> user is staff or an affiliate, the initial login screen will have to
> be able to handle either.
>
> Configuration of SAML IdPs will be generic, with software written to
> be able, theoretically, to handle any IdP. We just have to add
> appropriate configuration server side. As far as the user
> experience, on the login screen, each configured IdP will be displayed
> as an icon, and a line of text, both of which come from configuration.
> To login using SSO, user clicks one of these icons, authenticates, and
> is returned to Karl.
>
> Optionally, we can consider disabling password based authentication
> for users that should be logging in via SSO.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions

Yes, that is what we will need to do.

OK, sounds good. I'll start an email with Ajo and we can think through how this would work. I'm thinking we add a field on GSA that syncs over to KARL and becomes part of the user's profile (probably doesn't need to be exposed to the user, but I don't know) and lets KARL know what authentication provider the user has.

Thanks,
Nat

Yes. Exactly. Simple text field. Let's call it 'auth_method'. Possible
values: 'password', 'okta', 'google'. Pull down menu.

Chris

On Wed, Feb 8, 2017 at 10:14 AM, Nat Katin-Borland <
<email address hidden>> wrote:

> OK, sounds good. I'll start an email with Ajo and we can think through
> how this would work. I'm thinking we add a field on GSA that syncs over
> to KARL and becomes part of the user's profile (probably doesn't need to
> be exposed to the user, but I don't know) and lets KARL know what
> authentication provider the user has.
>
> Thanks,
> Nat
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to have any access
> to the system.
>
> An unknown user will be taken to /login.html, as is current practice.
> The SSO options will be added to the login screen. Visually, I'm not
> sure how that should work. But since we don't know, a priori, if a
> user is staff or an affiliate, the initial login screen will have to
> be able to handle either.
>
> Configuration of SAML IdPs will be generic, with software written to
> be able, theoretically, to handle any IdP. We just have to add
> appropriate configuration server side. As far as the user
> experience, on the login screen, each configured IdP will be displayed
> as an icon, and a line of text, both of which come from configuration.
> To login using SSO, user clicks one of these icons, authenticates, and
> is returned to Karl.
>
> Optionally, we can consider disabling password based authentication
> for users that should be logging in via SSO.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions
>

We should, for now, allow “none” as a choice.

—Paul

> On Feb 8, 2017, at 10:56 AM, Chris Rossi <email address hidden> wrote:
>
> Yes. Exactly. Simple text field. Let's call it 'auth_method'. Possible
> values: 'password', 'okta', 'google'. Pull down menu.
>
> Chris
>
> On Wed, Feb 8, 2017 at 10:14 AM, Nat Katin-Borland <
> <email address hidden>> wrote:
>
>> OK, sounds good. I'll start an email with Ajo and we can think through
>> how this would work. I'm thinking we add a field on GSA that syncs over
>> to KARL and becomes part of the user's profile (probably doesn't need to
>> be exposed to the user, but I don't know) and lets KARL know what
>> authentication provider the user has.
>>
>> Thanks,
>> Nat
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https://bugs.launchpad.net/bugs/1662250
>>
>> Title:
>> UX for SSO
>>
>> Status in KARL4:
>> New
>>
>> Bug description:
>> Basic vision for UX surrounding new SAML based SSO feature:
>>
>> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
>> addresses. Users arriving via SSO will be mapped to their Karl
>> profiles via email address. This requires that email address be
>> unique across all users. Will need to write a script to run against
>> production data to verify this is true. A user who is authenticated
>> via SSO must also have a profile in Karl in order to have any access
>> to the system.
>>
>> An unknown user will be taken to /login.html, as is current practice.
>> The SSO options will be added to the login screen. Visually, I'm not
>> sure how that should work. But since we don't know, a priori, if a
>> user is staff or an affiliate, the initial login screen will have to
>> be able to handle either.
>>
>> Configuration of SAML IdPs will be generic, with software written to
>> be able, theoretically, to handle any IdP. We just have to add
>> appropriate configuration server side. As far as the user
>> experience, on the login screen, each configured IdP will be displayed
>> as an icon, and a line of text, both of which come from configuration.
>> To login using SSO, user clicks one of these icons, authenticates, and
>> is returned to Karl.
>>
>> Optionally, we can consider disabling password based authentication
>> for users that should be logging in via SSO.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions
>>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order t...

I didn’t spot “password”, retract my comment.

—Paul

> On Feb 8, 2017, at 10:56 AM, Chris Rossi <email address hidden> wrote:
>
> Yes. Exactly. Simple text field. Let's call it 'auth_method'. Possible
> values: 'password', 'okta', 'google'. Pull down menu.
>
> Chris
>
> On Wed, Feb 8, 2017 at 10:14 AM, Nat Katin-Borland <
> <email address hidden>> wrote:
>
>> OK, sounds good. I'll start an email with Ajo and we can think through
>> how this would work. I'm thinking we add a field on GSA that syncs over
>> to KARL and becomes part of the user's profile (probably doesn't need to
>> be exposed to the user, but I don't know) and lets KARL know what
>> authentication provider the user has.
>>
>> Thanks,
>> Nat
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https://bugs.launchpad.net/bugs/1662250
>>
>> Title:
>> UX for SSO
>>
>> Status in KARL4:
>> New
>>
>> Bug description:
>> Basic vision for UX surrounding new SAML based SSO feature:
>>
>> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
>> addresses. Users arriving via SSO will be mapped to their Karl
>> profiles via email address. This requires that email address be
>> unique across all users. Will need to write a script to run against
>> production data to verify this is true. A user who is authenticated
>> via SSO must also have a profile in Karl in order to have any access
>> to the system.
>>
>> An unknown user will be taken to /login.html, as is current practice.
>> The SSO options will be added to the login screen. Visually, I'm not
>> sure how that should work. But since we don't know, a priori, if a
>> user is staff or an affiliate, the initial login screen will have to
>> be able to handle either.
>>
>> Configuration of SAML IdPs will be generic, with software written to
>> be able, theoretically, to handle any IdP. We just have to add
>> appropriate configuration server side. As far as the user
>> experience, on the login screen, each configured IdP will be displayed
>> as an icon, and a line of text, both of which come from configuration.
>> To login using SSO, user clicks one of these icons, authenticates, and
>> is returned to Karl.
>>
>> Optionally, we can consider disabling password based authentication
>> for users that should be logging in via SSO.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/karl4/+bug/1662250/+subscriptions
>>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1662250
>
> Title:
> UX for SSO
>
> Status in KARL4:
> New
>
> Bug description:
> Basic vision for UX surrounding new SAML based SSO feature:
>
> Identity Providers (IdPs, e.g. Okta, Google) will be providing email
> addresses. Users arriving via SSO will be mapped to their Karl
> profiles via email address. This requires that email address be
> unique across all users. Will need to write a script to run against
> production data to verify this is true. A user who is authenticated
> via SSO must also have a profile in Karl in order to...

Yep, I figured:)

I believe this is deployed and done. Any future work (bugs, refinements) can go in new tickets.