10:58 a.m.
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support:
* Conductor auth against LDAP with local DB Fallback
* conductor first tries authenticate user against external LDAP
server. If user is found there, user account in local db is created
(except credentials) if it doesn't exist yet. If user is not found in
LDAP, local db is searched.
* Keep Consistent With Katello
* This means Using DB as initial resource and falling back to LDAP
* if admin deletes a LDAP user in admin section, user is deleted
only from local db, but this user can login again (as she will be
authenticated against LDAP)
* user listing in conductor - shoud we list only local users or all
including LDAP?
* do we need UI for LDAP config (it's probably only IP + port,
maybe LDAP domain), if so we will need some table for saving
configuration (we don't have this yet)
* should be LDAP server setup part of aeolus-configure script? I
don't think so.
* but we should probably have something in aeolus-configure to make
conductor/etc aware of the ldap store
* IWHD Auth against:
* Conductor?
* warehouse should know about same set of users as conductor? No
* warehouse is going to support GSSAPI. So if someone is
authenticating to warehouse, identity check should be done against
conductor?
* LDAP?
* Should IWHD and imagefactory users be independent
* should IWHD authenticate always against conductor or against LDAP
or other resource? if not against conductor local db users won't have
access to iwhd
* Should ImageFactory Authenticate users?Yes
* Authentication across components
* Use OAuth?
* Already Support By Katello
* supports OAuth (two-legged), so it's not a problem for conductor
to be a 'consumer' of Katello service and use two-legged OAuth too (in
case conductor will use Katello as a service)
* OAuth Providers:
* Conductor
* IWHD?
* Will IWHD Support OAuth as well as GSSAPI?
* OAuth Clients
* aeolus-image
* imagefactory
* IWHD?
* if iwhd supports only GSSAPI (and should authenticate against
conductor) then conductor should act as GSSAPI server. Also user creds
in image build process will have to be passed through
aeolus-image->imagefactory->iwhd
* any other alternative to OAuth?
Task List
* Add LDAP support in conductor
* Update authentication model to auth againsts LDAP id available
* Create non existing users to local db
* Add OAuth Provider Support to
* Conductor
* IWHD?
* Add OAuth Client Support to
* Imagefactory
* aoelus-image
* IWHD?
* Add Deps to componets and fedora
* gem used in conductor for ldap auth, could be part of some more
sophisticated gem (devise, omniauth)
* oauth, gssapi libs
11:31 a.m.
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support:
* Conductor auth against LDAP with local DB Fallback
* conductor first tries authenticate user against external LDAP
server. If user is found there, user account in local db is created
(except credentials) if it doesn't exist yet. If user is not found in
LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for
authentication and configure SSSD.
It already provides all the functionality you are talking about.
* Local storage
* External LDAP auth
* Identity cache
We will be providing a special interface down the road but for now
simple wrappers around pam and nss calls would allow you to save you a
lot of time.
Do you want to explore it more?
* Keep Consistent With Katello
* This means Using DB as initial resource and falling back to LDAP
SSSD handles this.
* if admin deletes a LDAP user in admin section, user is
deleted
only from local db, but this user can login again (as she will be
authenticated against LDAP)
And this.
* user listing in conductor - shoud we list only local users or
all
including LDAP?
SSSD can create unified lists across local and LDAP domains if you
really need the list.
It can also return you groups and group membership for your access
control checks.
* do we need UI for LDAP config (it's probably only IP +
port,
maybe LDAP domain), if so we will need some table for saving
configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
* should be LDAP server setup part of aeolus-configure script?
I
don't think so.
This is a big question but if you set SSSD your test scripts then can
add local users to it do a dry run and test even withouth the external
LDAP server.
* but we should probably have something in aeolus-configure to
make
conductor/etc aware of the ldap store
* IWHD Auth against:
* Conductor?
IWHD authenticating against Conductor does not make sense. It
should be
against some identity source. Conductor is not a source. If we are
talking about IWHD connecting to Conductor then it depends how it
connects but I am not sure if this connection exsts. This is something
still not clear from other discussions on the list.
* warehouse should know about same set of users as conductor? No
IMO there is a big overlap between those so I would say yes. The store
should be in general the same. Just different groups within same
organization or community.
* warehouse is going to support GSSAPI. So if someone is
authenticating to warehouse, identity check should be done against
conductor?
Against IPA. GSSAPI gives you Kerberos SSO.
User authenticates against IPA and gets ticket to access IWHD.
Same should be generally with any component.
It is all covered on the diagrams that I sent a month ago however there
was not discussion or agreement about hose so I do not know if everybody
on the same page about it. It looks like it is not the case so far.
* LDAP?
It can be done using LDAP but then you would have to provide you
password on every command.
* Should IWHD and imagefactory users be independent
No. In context of the combined solution users come from one identity
source (at least for v1)
* should IWHD authenticate always against conductor or against
LDAP
or other resource? if not against conductor local db users won't have
access to iwhd
It looks like there is a lot of confusion. Can we have a meeting about it?
* Should ImageFactory Authenticate users?Yes
It depends. If IF does not expose CLI/UI directly then may be no.
We need to agree on the diagrams I sen a month ago before we can answer
these questions.
John, Hugh, should we have a formal review meeting?
* Authentication across components
Diagrams are about it...
* Use OAuth?
It depends.
* Already Support By Katello
* supports OAuth (two-legged), so it's not a problem for conductor
to be a 'consumer' of Katello service and use two-legged OAuth too (in
case conductor will use Katello as a service)
* OAuth Providers:
* Conductor
* IWHD?
* Will IWHD Support OAuth as well as GSSAPI?
* OAuth Clients
* aeolus-image
* imagefactory
* IWHD?
* if iwhd supports only GSSAPI (and should authenticate against
conductor) then conductor should act as GSSAPI server. Also user creds
in image build process will have to be passed through
aeolus-image->imagefactory->iwhd
Oh... Let us have a review... please!
* any other alternative to OAuth?
Before we move to the actions and tasks we should agree on the architecture.
Task List
* Add LDAP support in conductor
* Update authentication model to auth againsts LDAP id available
* Create non existing users to local db
* Add OAuth Provider Support to
* Conductor
* IWHD?
* Add OAuth Client Support to
* Imagefactory
* aoelus-image
* IWHD?
* Add Deps to componets and fedora
* gem used in conductor for ldap auth, could be part of some more
sophisticated gem (devise, omniauth)
* oauth, gssapi libs
_______________________________________________
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/
9:40 a.m.
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
> Identity
>
> Goals
> - support authentication against external LDAP
> - provide authentication mechanism across aeolus components
>
> Conversation Topics
>
> * LDAP Support:
>
> * Conductor auth against LDAP with local DB Fallback
>
> * conductor first tries authenticate user against external LDAP
> server. If user is found there, user account in local db is created
> (except credentials) if it doesn't exist yet. If user is not found in
> LDAP, local db is searched.
>
I wonder why reinvent the wheel. Can you use local pam stack for
authentication
Using PAM is an interesting idea. It does make the app more complicated
to install and configure, though. And makes it less portable. Also, I
don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support
assuming we retain the option of using Conductor's DB as an identity
store.
and configure SSSD.
SSD is what would give us the identity cache, right?
The motivation there was for laptop use cases, right? i.e. where you
want to be able to authenticate a user even when you can't reach the
LDAP server?
It already provides all the functionality you are talking about.
* Local storage
i.e. authenticate against /etc/shadow ?
* External LDAP auth
And lots of other auth options
* Identity cache
That's from SSD?
[..]
> * do we need UI for LDAP config (it's probably only IP
+ port,
> maybe LDAP domain), if so we will need some table for saving
> configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
All LDAP configuration is in sssd.conf? No extra PAM, nsswitch or
OpenLDAP config?
Cheers,
Mark.
9:58 a.m.
On Wed, 2011-08-03 at 15:40 +0100, Mark McLoughlin wrote:
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
> On 07/29/2011 11:58 AM, Martyn Taylor wrote:
> > Identity
> >
> > Goals
> > - support authentication against external LDAP
> > - provide authentication mechanism across aeolus components
> >
> > Conversation Topics
> >
> > * LDAP Support:
> >
> > * Conductor auth against LDAP with local DB Fallback
> >
> > * conductor first tries authenticate user against external LDAP
> > server. If user is found there, user account in local db is created
> > (except credentials) if it doesn't exist yet. If user is not found in
> > LDAP, local db is searched.
> >
>
> I wonder why reinvent the wheel. Can you use local pam stack for
> authentication
Using PAM is an interesting idea. It does make the app more complicated
to install and configure, though. And makes it less portable. Also, I
don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support
assuming we retain the option of using Conductor's DB as an identity
store.
Oh yes, as Simo pointed out, the other thing about PAM is that it
doesn't get us kerberos support - it's not a magic bullet on that front.
Cheers,
Mark.
6:56 p.m.
On 08/03/2011 10:58 AM, Mark McLoughlin wrote:
On Wed, 2011-08-03 at 15:40 +0100, Mark McLoughlin wrote:
> Hi Dmitri,
>
> On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
>> On 07/29/2011 11:58 AM, Martyn Taylor wrote:
>>> Identity
>>>
>>> Goals
>>> - support authentication against external LDAP
>>> - provide authentication mechanism across aeolus components
>>>
>>> Conversation Topics
>>>
>>> * LDAP Support:
>>>
>>> * Conductor auth against LDAP with local DB Fallback
>>>
>>> * conductor first tries authenticate user against external LDAP
>>> server. If user is found there, user account in local db is created
>>> (except credentials) if it doesn't exist yet. If user is not found in
>>> LDAP, local db is searched.
>>>
>> I wonder why reinvent the wheel. Can you use local pam stack for
>> authentication
> Using PAM is an interesting idea. It does make the app more complicated
> to install and configure, though. And makes it less portable. Also, I
> don't see much talk of Rails apps using PAM.
>
> All that being said, though, it might be a good option for LDAP support
> assuming we retain the option of using Conductor's DB as an identity
> store.
Oh yes, as Simo pointed out, the other thing about PAM is that it
doesn't get us kerberos support - it's not a magic bullet on that front.
I
am not sure we are talking about same scenario here. PAM gives you
kerberos support if you plan to authenticate users by prompting them for
their user credentials. In this case yes you can use user's Kerberos
password to authenticate him as pma can have pam_krb5 or sssd configured.
If you are talk about the case when user already authenticated using his
kerberos password and has TGT and tries to access Conductor using
browser the GSSAPI negotiation should kick in even before the
application decides to prompt user for credentials. In Apache mod_krb5
is in charge of this. So if negotiation is successful user is redirected
to the protected pages otherwise it can be an error or user can be
pointed to an unprotected page. These would be the pages where user is
asked for password and the whole PAM related sequence starts.
For GSSAPI negotiation to work now user and service (conductor) should
be members of the the same kerberos domain. In 80/20- use case user will
be using his windows machine to start the browser so either conductor
should be made a windows service or the conductor should be a part of
IPA domain (while user is a part of the AD domain) and there should be a
trust between IPA and AD. This is the functionality we are working on
now. Until it is there I do not see any value to be concerned with
GSSAPI negotiation and this PAM suits fine your needs.
Hope this clarifies things.
Cheers,
Mark.
_______________________________________________
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/
12:30 a.m.
On Wed, 2011-08-03 at 19:56 -0400, Dmitri Pal wrote:
> Oh yes, as Simo pointed out, the other thing about PAM is that
it
> doesn't get us kerberos support - it's not a magic bullet on that
> front.
I am not sure we are talking about same scenario here.
It was simply a warning to others that PAM isn't sufficient for ticket
based kerberos authentication.
It's easy to forget that PAM doesn't do this.
Cheers,
Mark.
6:40 p.m.
On 08/03/2011 10:40 AM, Mark McLoughlin wrote:
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
> On 07/29/2011 11:58 AM, Martyn Taylor wrote:
>> Identity
>>
>> Goals
>> - support authentication against external LDAP
>> - provide authentication mechanism across aeolus components
>>
>> Conversation Topics
>>
>> * LDAP Support:
>>
>> * Conductor auth against LDAP with local DB Fallback
>>
>> * conductor first tries authenticate user against external LDAP
>> server. If user is found there, user account in local db is created
>> (except credentials) if it doesn't exist yet. If user is not found in
>> LDAP, local db is searched.
>>
> I wonder why reinvent the wheel. Can you use local pam stack for
> authentication
Using PAM is an interesting idea. It does make the app more complicated
to install and configure, though. And makes it less portable. Also, I
don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support
assuming we retain the option of using Conductor's DB as an identity
store.
> and configure SSSD.
SSD is what would give us the identity cache, right?
Yes but not only.
The motivation there was for laptop use cases, right? i.e. where you
want to be able to authenticate a user even when you can't reach the
LDAP server?
The motivation is mostly to abstract from different identity sources and
authentication sources:
You can configure LDAP, AD, IPA, local files, or SSSD itself (it has
local indentity domain you are welcome to use).
The point is that your application does not need to know what is the
source. The source is configured outside the app.
> It already provides all the functionality you are talking about.
> * Local storage
i.e. authenticate against /etc/shadow ?
Not only. It has its own local user domain that you can use. It is not
local files.
> * External LDAP auth
And lots of other auth options
Yep.
> * Identity cache
That's from SSD?
SSSD, you missing one S which might be confusing as there is another
project called SSD.
SSSD caches identities from remote identity sources in the local DB so
for the applications on the system is does not really matter whether the
system is connected or not and where the identities come from. It can
cache credentials too and do local authentication when disconnect from
central source.
I understand that to take advantage of SSSD one now would have to
implement PAM calls and NSS libc calls. This is limiting and not convenient.
Next year we plan to provide a D-BUS interface that will have all sorts
of bindings for different languages. I hope that switch from PAM/NSS to
this interface would be really simple and straightforward. One of the
benefits of it will be the capability to decouple the application
identity space from the OS identity space. We see that this would be a
highly desirable feature. Think about SSSD in this case as a local
instance of SiteMinder. This is the path we are going. We are not there
yet but I want to layout the direction for you so that you have all the
information to make your implementation decision and not do the work
that can be avoided.
[..]
>> * do we need UI for LDAP config (it's probably only IP + port,
>> maybe LDAP domain), if so we will need some table for saving
>> configuration (we don't have this yet)
> If you go with SSSD it is not needed. Everything goes to sssd.conf
All LDAP configuration is in sssd.conf? No extra PAM, nsswitch or
OpenLDAP config?
Cheers,
Mark.
_______________________________________________
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/
12:57 p.m.
> The motivation there was for laptop use cases, right? i.e. where
you
> want to be able to authenticate a user even when you can't reach the
> LDAP server?
The motivation is mostly to abstract from different identity sources and
authentication sources:
You can configure LDAP, AD, IPA, local files, or SSSD itself (it has
local indentity domain you are welcome to use).
The point is that your application does not need to know what is the
source. The source is configured outside the app.
I do like this idea. Instead of supporting both LDAP / DB based
authentications and having to keep users in sync), perhaps in configure
we can have the admin select an authentication mechanism, configure it
(whether a new local install or an existing remote solution), and then
access it via PAM (or GSSAPI or whatever abstract authentication mechanism)
That way Aeolus could support whatever custom authentication scheme
whether or not it already deployed in an existing infrastructure (I'm
sure this will make alot of sysadmins happy :-) )
-Mo
12:57 p.m.
SSD is what would give us the identity cache, right?
The motivation there was for laptop use cases, right? i.e. where you
want to be able to authenticate a user even when you can't reach the
LDAP server?
Well conductor, iwhd, etc themselves would be the only ones
authenticating against LDAP correct? We would the end user communicate
w/ ldap directly?
-Mo
noon
* conductor first tries authenticate user against external
LDAP
server. If user is found there, user account in local db is created
(except credentials) if it doesn't exist yet. If user is not found in
LDAP, local db is searched.
* This means Using DB as initial resource and falling back to LDAP
These two bullets seem to contrast one another, the first you're saying
use LDAP first and in the 2nd your saying use the DB first.
* if admin deletes a LDAP user in admin section, user is
deleted
only from local db, but this user can login again (as she will be
authenticated against LDAP)
I'm not a fan of this, if an admin deletes a user, it is expected that
user is deleted and is not able to login again. An alternate approach
would be to introduce the notion of 'disabling' a user account
* do we need UI for LDAP config (it's probably only IP +
port,
maybe LDAP domain), if so we will need some table for saving
configuration (we don't have this yet)
I image a WUI to control LDAP has been implemented, perhaps this is just
finding the right one?
In any case, LDAP config is more suited for a yaml file written by
configure, not in a db in the database.
* should be LDAP server setup part of aeolus-configure script? I
don't think so.
I disagree, I think this should be an optional feature able to be setup
by configure. The configure script should also support being able to
specify an external location for an existing LDAP install (falling back
to setting it up locally if it doesn't exist).
All in all, IMO the user shouldn't be required to do anything to setup
aeolus other than install the rpms and run aeolus-configure.
-Mo
4642
days inactive
4648
days old
aeolus-devel@lists.fedorahosted.org
9 comments
4 participants
participants (4)
-
Dmitri Pal -
Mark McLoughlin -
Martyn Taylor -
Mo Morsi