[katello-devel] Design of SSO - screencast

[Marek Hulan]

On Monday 11 of March 2013 04:40:28 you wrote:
> ----- Original Message -----
> 
> | Hi,
> | 
> | sending answers in text below
> | 
> | On Sunday 10 of March 2013 09:13:04 you wrote:
> | > ----- Original Message -----
> | > 
> | > | Hey all
> | > | 
> | > | I just finished a short screencast about SSO design spike I
> | > | worked on
> | > | recently.
> | > | You can find on youtube
> | > | http://www.youtube.com/watch?v=4Ov771INMns
> | > | 
> | > | Comments or questions are welcome
> | > 
> | > Looking good, a few questions
> | > 
> | > 1. why are we authenticating to Katello? is this planned to be
> | > extracted
> | > back to the SSO app?
> | 
> | Because it's currently authoritative source of users and it knows
> | whether to
> | use LDAP or it's internal DB. However one of a first thing planned is
> | to learn
> | SSO app to communicate directly to LDAP.
> | 
> | > 2. how are we validating the cookie, is it short
> | > lived?
> | 
> | There is no validation of cookie and it should not be required.
> | Cookie does
> | not contain any important information, it's just a shortcut for
> | future login
> | to avoid some redirect. Currently cookie lives for 10 hours but this
> | is easy
> | to make it configurable.
> | 
> | > 3. how do i force idle timeout? should we still do it in
> | > katello/foreman?
> | 
> | Yes, I don't see any easy way we could implement this on SSO side.
> | Katello/Foreman must trigger SSO logout which then redirects to
> | Katello/Foreman logout action so you logout from SSO and your app.
> | 
> | > 4. would we support multiple backends? e.g. foreman now has the
> | > notion of
> | > authenticating against multiple auth sources (e.g. ldap / internal
> | > / ad) at
> | > the same time.
> | 
> | Since it's lightweight application it should not be hard to add new
> | backends.
> | Currently it supports only one - Katello, but it's a plan to add more
> | of them.
> | 
> | > 5. do you provide user details (e.g. ldap query can return
> | > additional user attributes such as email), or only authentication
> | > true /
> | > false? Foreman relay on such details (e.g. first name, last name,
> | > email
> | > etc) for auto creating the users in the database for their first
> | > login.
> | 
> | This is auth only system so only true/false. However OpenID which we
> | use has a
> | mechanism (SREG [1]) to share some information about user. It's not
> | implemented yet in our OpenID provider but it can be implemented if
> | needed.
> | 
> | Let me know if you have further questions.
> | Thank you
> 
> Thanks Marek,
> 
> My main concern is that this would not be a drop in replacement for current
> foreman users, and we would need to maintain multiple SSO backends (e.g.
> what foreman currently has with Apache) or plain authentication ( e.g. it
> wont answer get user details ).
I'm not sure whether I get it right but this SSO application was not meant to 
be any replacement. Users would not be forced to use it at all. It should 
allow users only one thing that it's named after - they just sign in once and 
they can use other systems immediately. The only thing that's needed from 
Foreman point of view is adding support for custom OpenID provider. 

It's 39 LOC including whitelines and comments. The biggest benefit would be 
that Katello and Foreman (and maybe other systems) would not have to implement 
various authentication methods separately. It means having kerberos, LDAP and 
e.g. OpenID authentication on one place and reused by all applications. Hence 
you could remove some SSO backends you may already have in Foreman.

Does it make sense? What should this SSO solution fulfill to meet Foreman 
requirements?

Thanks
-- 
Marek