[katello-devel] Design of SSO - screencast

[Ohad Levy]

----- Original Message -----
| On Monday 11 of March 2013 08:57:49 you wrote:
| > ----- Original Message -----
| > 
| > | On Monday 11 of March 2013 08:31:27 Ohad Levy wrote:
| > | > | > 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?
| > | > 
| > | > The issue here, is that you would need to configure ldap twice,
| > | > once for SSO
| > | > app to authenticate, and the other time for foreman to query
| > | > user/group
| > | > information.
| > | > 
| > | > this means you store the pw twice, and also means that i cant
| > | > get
| > | > rid of the
| > | > ldap related code in foreman.
| > | 
| > | Why this can't be the same LDAP instance? It would only make
| > | sense to
| > | have one
| > | DB of users. You are right, LDAP code would have to stay in
| > | Foreman
| > | to gather
| > | information about users. Unless we implement some REST API in SSO
| > | to
| > | provide
| > | user information however this is something I'd like to avoid. It
| > | would result
| > | in adding another layer that would just translate data.
| > 
| > my point is, that if you need an account to authenticate to ldap
| > (e.g. plain
| > users might not have bind rights, or search rights etc), you would
| > need to
| > store that account password twice.
| Right but those should be two separate accounts anyway. SSO app
| should have
| the lowest privileges possible however Foreman could need access to
| groups and
| maybe other stuff.

I'm not sure thats a valid argument, in any case, you do end up maintaining to sets of code (per provider * Num of Apps using SSO) and also storing the credentials multiple times on different systems in an unencrypted form.

I would rather see a more complete solution, where all user based queries are done via that service.

Ohad