KARL4

Bug #1662250
Comment #18

Comment 18 for bug 1662250

Revision history for this message

Chris Rossi (chris-archimedeanco) wrote on 2017-02-08: Re: [Bug 1662250] Re: UX for SSO

#18

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
>

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 <
nathaniel.katin-borland@opensocietyfoundations.org> 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
>