On 08/03/2011 02:07 AM, Dmitri Pal wrote:
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.
Well, this is more management decision, but sounds good to me. Only
concern is if IPA is supported by authentication framework we will use
in Conductor and Katello (whichever we use finally).
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
In scenario I described, password for users in AD (or other external
identity system) is not saved in local app DB.
application database will just contain data associated with user
accounts and IPA will be you user storage. In future we will add cross
What you are proposing is that we will keep whole User model outside,
this has 2 disadvantages:
- we would have to query IPA anytime when a user info is needed, for
example when listing permissions for an object -> this could be
potential performance issue
- when user is deleted in IPA, we still have data associated with the
user in our app
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.
I think that we want to keep User model in our local DB, but it's
possible I'm wrong.
> Jan
> _______________________________________________
> aeolus-devel mailing list
> aeolus-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/aeolus-devel