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