Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-20 Thread Adam Young
On 10/16/2014 02:58 PM, David Chadwick wrote: Dave when federation is used, the user's group is stored in a mapping rule. So we do have a mechanism for storing group memberships without using LDAP or creating an entry for the user in the SQL backend. (The only time this is kinda not true is if w

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-20 Thread Adam Young
On 10/16/2014 03:18 PM, Dave Walker wrote: On 16 October 2014 20:07, David Stanek wrote: I may be missing something, but can you use the external auth method with the LDAP backend? No, as the purpose of the LDAP backend is to validate user/pass combination are valid. With the external auth

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Nathan Kinder
On 10/16/2014 12:30 PM, Dave Walker wrote: > Hi, > > I think I considered the Federated plugin as a mismatch as it dealt > with 'remote' auth rather than 'external' auth. I thought it was for > purely handling SSO / SAML2, and not being subordinate to auth with > the webserver. > > I'll dig in

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Dave Walker
Hi, I think I considered the Federated plugin as a mismatch as it dealt with 'remote' auth rather than 'external' auth. I thought it was for purely handling SSO / SAML2, and not being subordinate to auth with the webserver. I'll dig into the federation plugin more, thanks. -- Kind Regards, Dave

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Dave Walker
On 16 October 2014 20:07, David Stanek wrote: > I may be missing something, but can you use the external auth method with > the LDAP backend? > No, as the purpose of the LDAP backend is to validate user/pass combination are valid. With the external auth plugin, these are not provided to keyston

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread David Stanek
On Thu, Oct 16, 2014 at 2:54 PM, Dave Walker wrote: > Hi Steve, > > Thanks for your response. I am talking generally about the external > auth support. One use case is Kerberos, but for the sake of argument > this could quite easily be Apache Basic auth. The point is, we have > current support

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread David Chadwick
Dave when federation is used, the user's group is stored in a mapping rule. So we do have a mechanism for storing group memberships without using LDAP or creating an entry for the user in the SQL backend. (The only time this is kinda not true is if we have a specific rule for each federated user,

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Dave Walker
pment Mailing List >> , >> Date: 10/16/2014 02:20 PM >> Subject: [openstack-dev] [Keystone] external AuthN Identity Backend >> >> Hi, >> >> Currently we have two ways of doing Identity Auth backends, these are >> sql and ldap. >> >> The SQL

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Steve Martinelli
Dave Walker wrote on 10/16/2014 02:15:07 PM: > From: Dave Walker > To: OpenStack Development Mailing List , > Date: 10/16/2014 02:20 PM > Subject: [openstack-dev] [Keystone] external AuthN Identity Backend > > Hi, > > Currently we have two ways of doing Identity Auth

[openstack-dev] [Keystone] external AuthN Identity Backend

2014-10-16 Thread Dave Walker
Hi, Currently we have two ways of doing Identity Auth backends, these are sql and ldap. The SQL backend is the default and is for situations where Keyston is the canonical Identity provider with username / password being directly compared to the Keystone database. LDAP is the current option if K