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
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
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
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
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
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
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,
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
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
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
10 matches
Mail list logo