On 08/02/2011 10:01 AM, Jan Provazník wrote:
Hi,
sending identity user stories we put together with Martyn.
As a user I should be able to share identity in Conductor and katello
* Check up on Katello see whether it uses Warden or OmniAuth and
what the situation is re: migrating to OmniAuth if not already
there
* Use same authentication framework in Conductor and Katello (either
OmniAuth or Warden) depending on above result, this framework
should support Active Directory and SSO
* add rpms dependencies to Conductor
* implment SSO for Conductor and Katello
As an admin I should have running identity server after installing
Conductor
* In aeolus-configure point conductor to existing AD server or set
up own identity server (LDAP?) if no AD is available
If AD is not available you can use IPA. At least that was the plan when
the identity management was discussed at early stages of the project.
RHEV-M already did such integration so you can check with Itamar all the
details and take advantage of what already has been done.
IMO IPA should always be installed and configured for password synch if
there is AD and be your controlled storage otherwise. In this case you
do not need to create and store passwords in your database. You
application database will just contain data associated with user
accounts and IPA will be you user storage. In future we will add cross
kerberos trust support so instead of the synchronization you would be
able to take advantage of Kerberos SSO between AD and IPA.
IMO this rout would save you some cycles in future. Also think about all
security audits and compliance issues once you introduce password
storage into your application.
As an admin I should be able to create local users for Conductor
(Conductor local users doesn't need to have access to Katello)
* check up on Katello and do it same way - it probably already
supports this, if it doesn't then steps are:
* when authenticating a user, first authenticate against local db
* if the user is not found in local db, authenticate against LDAP
* if auth is successful, create this user in local conductor DB
too, but without password so user has to be authenticated always
against LDAP
* add some flag to distinguish between local/no-local users in user
listing
* allow editing only some settings (quota) for no-local users
I continue to wonder why this pattern is being used?
If you need local users use local instance of IPA, DS, SSSD that you
control and configure. Decouple your app from dealing with
authentication and getting account data - rely on the external source.
It will help you to get into much more complex identity related
scenarios down the road without re-factoring your solution.
Jan
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/