Comment 19 for bug 1662250

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