Initial thoughts for Release 0.4.0 from Identity planning meeting:
Support authentication against external LDAP
Conductor will integrate with LDAP Server for authentication. It will follow the same principles as Katello, in that it will use the local DB as its primary data source for users and fall back on LDAP (TBC). e.g. If a user does not already exist in the local DB it will: 1) authenticate against LDAP 2) create the user in the DB.
Deleting users will consist of deleting the user in the local DB only. this can then be created again, the next time a user logs in using LDAP Auth.
Listing users in Conductor, will consist of only listing the users in the local database. Warehouse should share the same set of users as conductor. Warehouse is likely supporting GSSAPI. We need to decide whether warehouse will be authenticating against conductor or another service.
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
On 30/07/2011, at 3:57 AM, Martyn Taylor wrote:
Initial thoughts for Release 0.4.0 from Identity planning meeting:
[...]
Deleting users will consist of deleting the user in the local DB only. this can then be created again, the next time a user logs in using LDAP Auth.
I'm sure to be missing something here but what is the purpose of deleting a user if they are just re-created next time? Just aesthetics?
On 08/01/2011 06:31 AM, Simon Harris wrote:
On 30/07/2011, at 3:57 AM, Martyn Taylor wrote:
Initial thoughts for Release 0.4.0 from Identity planning meeting:
[...]
Deleting users will consist of deleting the user in the local DB only. this can then be created again, the next time a user logs in using LDAP Auth.
I'm sure to be missing something here but what is the purpose of deleting a user if they are just re-created next time? Just aesthetics?
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Really the recreate is really an implementation detail of how the initial create user is to work. Allowing automatic creation of users once they are authenticated in LDAP.
All the relationships etc... that are associated with the user will be permanently deleted. A new create would create a completely fresh user.
On 07/29/2011 07:57 PM, Martyn Taylor wrote:
Initial thoughts for Release 0.4.0 from Identity planning meeting:
Support authentication against external LDAP
Conductor will integrate with LDAP Server for authentication. It will follow the same principles as Katello, in that it will use the local DB as its primary data source for users and fall back on LDAP (TBC). e.g. If a user does not already exist in the local DB it will: 1) authenticate against LDAP 2) create the user in the DB.
Deleting users will consist of deleting the user in the local DB only. this can then be created again, the next time a user logs in using LDAP Auth.
Nit: maybe users could be flagged (ldap/local) and deletion could be supported only for local users.
Listing users in Conductor, will consist of only listing the users in the local database. Warehouse should share the same set of users as conductor. Warehouse is likely supporting GSSAPI. We need to decide whether warehouse will be authenticating against conductor or another service.
We need to list both local and LDAP users as there are some user settings required for all users (for example quota).
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place. _______________________________________________ aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
Cheers, Mark.
On 08/03/2011 10:45 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
As well as Katello -> Conductor and Conductor -> Katello.
-- bk
On Wed, Aug 03, 2011 at 11:27:04AM -0400, Bryan Kearney wrote:
On 08/03/2011 10:45 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
As well as Katello -> Conductor and Conductor -> Katello.
Yes.
To be clear, I think we may be able to get away with no authorization in the warehouse at all -- at least until someone proves to me we need it.
If Conductor is the only thing that talks to the warehouse and the factory, and we think the ability of an admin to add or remove items from a Conductor catalog is sufficient access control for images (I do), then we don't really need warehouse to do authentication at all -- we just need to secure the connection.
--Hugh
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
As well as Katello -> Conductor and Conductor -> Katello.
Sorry if I'm jumping into the discussion a little late but why are all these services authenticating against each other?
For that matter why do we store any authentication details in the db?
Why not setup a single central LDAP server and have everything authenticate against that, eg conductor, katello, candlepin, pulp, etc.
This may just be my opinion but I feel we replicate way too much data w/ aeolus, LDAP is meant for high performance authentication, and is simple to setup and use.
-Mo
On 08/04/2011 12:45 PM, Mo Morsi wrote:
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
As well as Katello -> Conductor and Conductor -> Katello.
Sorry if I'm jumping into the discussion a little late but why are all these services authenticating against each other?
For that matter why do we store any authentication details in the db?
Why not setup a single central LDAP server and have everything authenticate against that, eg conductor, katello, candlepin, pulp, etc.
This may just be my opinion but I feel we replicate way too much data w/ aeolus, LDAP is meant for high performance authentication, and is simple to setup and use.
Yes but not all component really need authentication. As long as it is an internal component it just needs a trusted connection to a peer. If we are talking about externally facing components like Conductor and Katello there are always two options: 1) Use central auth store with SSO (that would be AD or IPA as pure LDAP does not provide SSO) and perform operations using end user identity when one component needs to talk to another 2) Create a separate channel on a separate port. This connection just requires server to server trust. It can be OAuth, SSL, Kerberos or other similar technology.
-Mo
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Sorry if I'm jumping into the discussion a little late but why are all these services authenticating against each other?
For that matter why do we store any authentication details in the db?
Why not setup a single central LDAP server and have everything authenticate against that, eg conductor, katello, candlepin, pulp, etc.
This may just be my opinion but I feel we replicate way too much data w/ aeolus, LDAP is meant for high performance authentication, and is simple to setup and use.
Yes but not all component really need authentication. As long as it is an internal component it just needs a trusted connection to a peer.
Thats fine, those components would be unaffected by all of this
If we are talking about externally facing components like Conductor and Katello there are always two options:
- Use central auth store with SSO (that would be AD or IPA as pure LDAP
does not provide SSO) and perform operations using end user identity when one component needs to talk to another
If we're just talking about the web interfaces couldn't we just use a shared cookie or similar? Then when communicating between conductor / katello on the backend, we just need to simply pass around the current logged in user over a trusted connection, no need for auth between those components.
- Create a separate channel on a separate port. This connection just
requires server to server trust. It can be OAuth, SSL, Kerberos or other similar technology.
I don't have much experience w/ it, but OAuth seems to be quickly becoming a standard for these matters. Perhaps supporting OAuth logins into conductor and katello would be a good solution?
-Mo
On 08/04/2011 02:30 PM, Mo Morsi wrote:
Sorry if I'm jumping into the discussion a little late but why are all these services authenticating against each other?
For that matter why do we store any authentication details in the db?
Why not setup a single central LDAP server and have everything authenticate against that, eg conductor, katello, candlepin, pulp, etc.
This may just be my opinion but I feel we replicate way too much data w/ aeolus, LDAP is meant for high performance authentication, and is simple to setup and use.
Yes but not all component really need authentication. As long as it is an internal component it just needs a trusted connection to a peer.
Thats fine, those components would be unaffected by all of this
If we are talking about externally facing components like Conductor and Katello there are always two options:
- Use central auth store with SSO (that would be AD or IPA as pure LDAP
does not provide SSO) and perform operations using end user identity when one component needs to talk to another
If we're just talking about the web interfaces couldn't we just use a shared cookie or similar? Then when communicating between conductor / katello on the backend, we just need to simply pass around the current logged in user over a trusted connection, no need for auth between those components.
- Create a separate channel on a separate port. This connection just
requires server to server trust. It can be OAuth, SSL, Kerberos or other similar technology.
I don't have much experience w/ it, but OAuth seems to be quickly becoming a standard for these matters. Perhaps supporting OAuth logins into conductor and katello would be a good solution?
I think you talk about 3 legged OAuth in this case or something like CAS. I see 2 problems with this: a) IPA would need to support OAuth or CAS. It does not. It is something that can be done if this is the path everybody is going but this effort is not on the road map and unstaffed b) You loose the enterprise SSO technologies that are available. You can't use native GSSAPI with Kerberos. Original plan was that this is the direction so later the servers can talk to each other using Kerberos ticket delegation or service to service Kerberos trust like S4you. Also you forget that if you have mixed environment like AD and IPA and your cloud infrastructure is running on the Linux machines managed by IPA you want to have trusts between domains.
My point is that asking password at the boundary of the web app is bad. Best would be - you authenticated into your workstation as a user and this auth is respected across applications running in the enterprise regardless what domain (AD or IPA you are from). IPA provides that or works into this direction. With OAuth or other pure web based solutions things are simpler but limiting in a longer run. But I suspect there be a lock in into specific technology and our plans for real enterprise SSO down the road would become unachievable.
-Mo _______________________________________________ aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 08/03/2011 10:45 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
Exactly! I am just struggling with understanding why and how it is better than say SSL? Is it faster? Is there a good key management infrastructure and tools? If yes - great if no should we be worried about this and pick other credentials that we already have tools for?
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Wed, 2011-08-03 at 19:43 -0400, Dmitri Pal wrote:
On 08/03/2011 10:45 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
Exactly! I am just struggling with understanding why and how it is better than say SSL? Is it faster? Is there a good key management infrastructure and tools? If yes - great if no should we be worried about this and pick other credentials that we already have tools for?
I assume two legged OAuth was chosen over X.509 client certificates purely for the sake of simplicity.
Cheers, Mark.
On 08/04/2011 01:26 AM, Mark McLoughlin wrote:
On Wed, 2011-08-03 at 19:43 -0400, Dmitri Pal wrote:
On 08/03/2011 10:45 AM, Mark McLoughlin wrote:
On Fri, 2011-07-29 at 18:57 +0100, Martyn Taylor wrote:
We intend to use OAuth across components for authentication. This would require adding OAuth Provider support to conductor and OAuth client support to each component accessing protected resources. Katello already supports a OAuth (two-legged) which hopefully means relatively straight forward integration once we have the other parts in place.
I think there's been some confusion about OAuth, what Katello uses it for and what we would use it for.
In Katello's case, it is actually an OAuth consumer and uses it when authenticating against Candlepin and Pulp's REST APIs.
Two-legged means that Candlepin/Pulp don't authenticate a user, but rather authenticate Katello using a shared secret. Katello passes Candlepin/Pulp the username via a HTTP header.
IMHO, the comparable case for us is Conductor authenticating against IWHD and Image Factory.
Exactly! I am just struggling with understanding why and how it is better than say SSL? Is it faster? Is there a good key management infrastructure and tools? If yes - great if no should we be worried about this and pick other credentials that we already have tools for?
I assume two legged OAuth was chosen over X.509 client certificates purely for the sake of simplicity.
Yes. It assumes a common namespace for users, and that is all.
-- bk
aeolus-devel@lists.fedorahosted.org