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 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 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