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 dsta...@dstanek.com wrote:
SNIP

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 keystone (and may not even exist).  If they did exist, we
would be doing auth at the edge and at the backend - which seems
needlessly expensive.

--
Kind Regards,
Daviey Walker

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

The short of it  is that what you are describing is handled by Federation.

I think that there is some confusing in the processing of an authN/authZ 
request which we call create a token


Here's how I would expect it to work in a Kerberos case (the archetype 
for external) before the use of Federation


1.  mod_auth_kerb authenticates the user and sets REMOTE_USER before 
calling the Keystone WSGI app

2.  Keystone accepts REMOTE_USER and looks up the user in LDAP to get groups
3.  Userid and Groups are used to  fetch roles to populate the token

We can also use the OSand mod_lookup_identity to get us Groups:  see 
this write up for how to use Federation with SSSD


http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/

That is old and needs to be updated, but the concepts are the same.


With Federation, you provide a mapping and a bunch of env vars to the 
Keystone server, and there is no need to persist the user in the user table.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 we have a specific rule for each
federated user, so that then each mapping rule is equivalent to an entry
for each user). But usually we might expect many users to use the same
mapping rule.

Mapping rules should be usable for Kerberos logins. I dont know if the
current code does have this ability or not, but if it doesn't, then it
should be re-engineered to. (it was always in my design that all remote
logins should have a mapping capability)
I most certainly does, and can be extended to get additional env vars 
from mod_lookup_identity as well.





regards

David

On 16/10/2014 19:15, Dave Walker wrote:

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 Keystone isn't the canonical Identity
provider and passes the username and password to an LDAP server for
comparison and retrieves the groups.

For a few releases we have supported External auth (or Kerberos),
where we authenticate the user at the edge and trust the REMOTE_USER
is valid.  In these situations Keystone doesn't require the Username
or Password to be valid.

Particularly in Kerberos situations, no password is used to
successfully authenticate at the edge.  This works well, but LDAP
cannot be used as no password is passed through.  The other option is
SQL, but that then requires a user to be created in Keystone first.

We do not seem to cover the situation where Identity is provided by an
external mechanism.  The only system currently available is Federation
via SAML, which isn't always the best fit.

Therefore, I'd like to suggest the introduction of a third backend.
This would be the external identity provider.  This would seem to be
pretty simple, as the current checks would simply return success (as
we trust auth at the edge), and not store user_id in the database, but
generate it at runtime.

The issue I have, is that this doesn't cover Group membership.

So, am I a:
  - Barking totally up the wrong tree
  - Add support to the current LDAP plugin to support external auth
(but still use LDAP for groups)
  - Write a standalone external plugin, but then do what for Groups?  I
would be reasonably happy to just have 1:1 mapping of users to groups.

Does this make sense?

Thanks

--
Kind Regards,
Daviey Walker

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-10-16 Thread Steve Martinelli
I think it depends on what you mean by
'external identity provider'
- I assume it's capable of speaking some sort of federation protocol. So
I'd rather explore adding more support for additional federation protocols/standards,
rather than making our own third backend. 

Steve

Dave Walker em...@daviey.com wrote on 10/16/2014
02:15:07 PM:

 From: Dave Walker em...@daviey.com
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org,

 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 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 Keystone isn't the canonical Identity
 provider and passes the username and password to an LDAP server for
 comparison and retrieves the groups.
 
 For a few releases we have supported External auth (or Kerberos),
 where we authenticate the user at the edge and trust the REMOTE_USER
 is valid. In these situations Keystone doesn't require the Username
 or Password to be valid.
 
 Particularly in Kerberos situations, no password is used to
 successfully authenticate at the edge. This works well, but
LDAP
 cannot be used as no password is passed through. The other option
is
 SQL, but that then requires a user to be created in Keystone first.
 
 We do not seem to cover the situation where Identity is provided by
an
 external mechanism. The only system currently available is Federation
 via SAML, which isn't always the best fit.
 
 Therefore, I'd like to suggest the introduction of a third backend.
 This would be the external identity provider. This would seem
to be
 pretty simple, as the current checks would simply return success (as
 we trust auth at the edge), and not store user_id in the database,
but
 generate it at runtime.
 
 The issue I have, is that this doesn't cover Group membership.
 
 So, am I a:
 - Barking totally up the wrong tree
 - Add support to the current LDAP plugin to support external
auth
 (but still use LDAP for groups)
 - Write a standalone external plugin, but then do what for Groups?
I
 would be reasonably happy to just have 1:1 mapping of users to groups.
 
 Does this make sense?
 
 Thanks
 
 --
 Kind Regards,
 Daviey Walker
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-10-16 Thread Dave Walker
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 for entrusting AuthN outside of Keystone.

What I was trying to outline is that it seems that the current design
of external auth is that keystone is not in the auth pipeline as we
trust auth at the edge.  However, we then do additional auth within
keystone.

With external auth and SQL, we drop the user provided username and
password on the floor and use what was provided in REMOTE_USER (set by
the webserver).

Therefore the check as it currently stands in SQL is basically 'is
this username in the database'.  The LDAP plugin does Authentication
via username and password, which is clearly not sufficient for
external auth.  The LDAP plugin could be made to check in a similar
manner to SQL 'is this a valid user' - but this would seem to be a
duplicate check, as we already did this at the edge.

If the webserver granted access to keystone, the user has already been
checked to see if they are a valid user.  However, your response seems
to suggest that current external auth should be formally deprecated?

--
Kind Regards,
Daviey Walker

On 16 October 2014 19:28, Steve Martinelli steve...@ca.ibm.com wrote:
 I think it depends on what you mean by 'external identity provider' - I
 assume it's capable of speaking some sort of federation protocol. So I'd
 rather explore adding more support for additional federation
 protocols/standards, rather than making our own third backend.

 Steve

 Dave Walker em...@daviey.com wrote on 10/16/2014 02:15:07 PM:

 From: Dave Walker em...@daviey.com
 To: OpenStack Development Mailing List
 openstack-dev@lists.openstack.org,
 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 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 Keystone isn't the canonical Identity
 provider and passes the username and password to an LDAP server for
 comparison and retrieves the groups.

 For a few releases we have supported External auth (or Kerberos),
 where we authenticate the user at the edge and trust the REMOTE_USER
 is valid.  In these situations Keystone doesn't require the Username
 or Password to be valid.

 Particularly in Kerberos situations, no password is used to
 successfully authenticate at the edge.  This works well, but LDAP
 cannot be used as no password is passed through.  The other option is
 SQL, but that then requires a user to be created in Keystone first.

 We do not seem to cover the situation where Identity is provided by an
 external mechanism.  The only system currently available is Federation
 via SAML, which isn't always the best fit.

 Therefore, I'd like to suggest the introduction of a third backend.
 This would be the external identity provider.  This would seem to be
 pretty simple, as the current checks would simply return success (as
 we trust auth at the edge), and not store user_id in the database, but
 generate it at runtime.

 The issue I have, is that this doesn't cover Group membership.

 So, am I a:
  - Barking totally up the wrong tree
  - Add support to the current LDAP plugin to support external auth
 (but still use LDAP for groups)
  - Write a standalone external plugin, but then do what for Groups?  I
 would be reasonably happy to just have 1:1 mapping of users to groups.

 Does this make sense?

 Thanks

 --
 Kind Regards,
 Daviey Walker

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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, so that then each mapping rule is equivalent to an entry
for each user). But usually we might expect many users to use the same
mapping rule.

Mapping rules should be usable for Kerberos logins. I dont know if the
current code does have this ability or not, but if it doesn't, then it
should be re-engineered to. (it was always in my design that all remote
logins should have a mapping capability)

regards

David

On 16/10/2014 19:15, Dave Walker wrote:
 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 Keystone isn't the canonical Identity
 provider and passes the username and password to an LDAP server for
 comparison and retrieves the groups.
 
 For a few releases we have supported External auth (or Kerberos),
 where we authenticate the user at the edge and trust the REMOTE_USER
 is valid.  In these situations Keystone doesn't require the Username
 or Password to be valid.
 
 Particularly in Kerberos situations, no password is used to
 successfully authenticate at the edge.  This works well, but LDAP
 cannot be used as no password is passed through.  The other option is
 SQL, but that then requires a user to be created in Keystone first.
 
 We do not seem to cover the situation where Identity is provided by an
 external mechanism.  The only system currently available is Federation
 via SAML, which isn't always the best fit.
 
 Therefore, I'd like to suggest the introduction of a third backend.
 This would be the external identity provider.  This would seem to be
 pretty simple, as the current checks would simply return success (as
 we trust auth at the edge), and not store user_id in the database, but
 generate it at runtime.
 
 The issue I have, is that this doesn't cover Group membership.
 
 So, am I a:
  - Barking totally up the wrong tree
  - Add support to the current LDAP plugin to support external auth
 (but still use LDAP for groups)
  - Write a standalone external plugin, but then do what for Groups?  I
 would be reasonably happy to just have 1:1 mapping of users to groups.
 
 Does this make sense?
 
 Thanks
 
 --
 Kind Regards,
 Daviey Walker
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 em...@daviey.com 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 for entrusting AuthN outside of Keystone.

 What I was trying to outline is that it seems that the current design
 of external auth is that keystone is not in the auth pipeline as we
 trust auth at the edge.  However, we then do additional auth within
 keystone.

 With external auth and SQL, we drop the user provided username and
 password on the floor and use what was provided in REMOTE_USER (set by
 the webserver).

 Therefore the check as it currently stands in SQL is basically 'is
 this username in the database'.  The LDAP plugin does Authentication
 via username and password, which is clearly not sufficient for
 external auth.  The LDAP plugin could be made to check in a similar
 manner to SQL 'is this a valid user' - but this would seem to be a
 duplicate check, as we already did this at the edge.

 If the webserver granted access to keystone, the user has already been
 checked to see if they are a valid user.  However, your response seems
 to suggest that current external auth should be formally deprecated?


I may be missing something, but can you use the external auth method with
the LDAP backend?

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-10-16 Thread Dave Walker
On 16 October 2014 20:07, David Stanek dsta...@dstanek.com wrote:
SNIP
 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 keystone (and may not even exist).  If they did exist, we
would be doing auth at the edge and at the backend - which seems
needlessly expensive.

--
Kind Regards,
Daviey Walker

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 Walker

On 16 October 2014 19:58, David Chadwick d.w.chadw...@kent.ac.uk 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 we have a specific rule for each
 federated user, so that then each mapping rule is equivalent to an entry
 for each user). But usually we might expect many users to use the same
 mapping rule.

 Mapping rules should be usable for Kerberos logins. I dont know if the
 current code does have this ability or not, but if it doesn't, then it
 should be re-engineered to. (it was always in my design that all remote
 logins should have a mapping capability)

 regards

 David

 On 16/10/2014 19:15, Dave Walker wrote:
 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 Keystone isn't the canonical Identity
 provider and passes the username and password to an LDAP server for
 comparison and retrieves the groups.

 For a few releases we have supported External auth (or Kerberos),
 where we authenticate the user at the edge and trust the REMOTE_USER
 is valid.  In these situations Keystone doesn't require the Username
 or Password to be valid.

 Particularly in Kerberos situations, no password is used to
 successfully authenticate at the edge.  This works well, but LDAP
 cannot be used as no password is passed through.  The other option is
 SQL, but that then requires a user to be created in Keystone first.

 We do not seem to cover the situation where Identity is provided by an
 external mechanism.  The only system currently available is Federation
 via SAML, which isn't always the best fit.

 Therefore, I'd like to suggest the introduction of a third backend.
 This would be the external identity provider.  This would seem to be
 pretty simple, as the current checks would simply return success (as
 we trust auth at the edge), and not store user_id in the database, but
 generate it at runtime.

 The issue I have, is that this doesn't cover Group membership.

 So, am I a:
  - Barking totally up the wrong tree
  - Add support to the current LDAP plugin to support external auth
 (but still use LDAP for groups)
  - Write a standalone external plugin, but then do what for Groups?  I
 would be reasonably happy to just have 1:1 mapping of users to groups.

 Does this make sense?

 Thanks

 --
 Kind Regards,
 Daviey Walker

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 into the federation plugin more, thanks.

There are some plans to be able to frontend the user/group lookup in
httpd like you ca do with external auth.  This is similar to the
federation approach.  I've written up some details here:

  https://blog-nkinder.rhcloud.com/?p=130

There is still work to do to tie in the mapping code from the
OS-FEDERATION extension, but I think the approach shows a lot of
promise.  Choose your auth module (mod_auth_kerb, mod_ssl, etc.) to set
REMOTE_USER, then use mod_lookup_identity to supply the user/group info
from LDAP.  This is an approach that should get some discussion time at
the Summit.

Thanks,
-NGK

 
 --
 Kind Regards,
 Dave Walker
 
 On 16 October 2014 19:58, David Chadwick d.w.chadw...@kent.ac.uk 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 we have a specific rule for each
 federated user, so that then each mapping rule is equivalent to an entry
 for each user). But usually we might expect many users to use the same
 mapping rule.

 Mapping rules should be usable for Kerberos logins. I dont know if the
 current code does have this ability or not, but if it doesn't, then it
 should be re-engineered to. (it was always in my design that all remote
 logins should have a mapping capability)

 regards

 David

 On 16/10/2014 19:15, Dave Walker wrote:
 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 Keystone isn't the canonical Identity
 provider and passes the username and password to an LDAP server for
 comparison and retrieves the groups.

 For a few releases we have supported External auth (or Kerberos),
 where we authenticate the user at the edge and trust the REMOTE_USER
 is valid.  In these situations Keystone doesn't require the Username
 or Password to be valid.

 Particularly in Kerberos situations, no password is used to
 successfully authenticate at the edge.  This works well, but LDAP
 cannot be used as no password is passed through.  The other option is
 SQL, but that then requires a user to be created in Keystone first.

 We do not seem to cover the situation where Identity is provided by an
 external mechanism.  The only system currently available is Federation
 via SAML, which isn't always the best fit.

 Therefore, I'd like to suggest the introduction of a third backend.
 This would be the external identity provider.  This would seem to be
 pretty simple, as the current checks would simply return success (as
 we trust auth at the edge), and not store user_id in the database, but
 generate it at runtime.

 The issue I have, is that this doesn't cover Group membership.

 So, am I a:
  - Barking totally up the wrong tree
  - Add support to the current LDAP plugin to support external auth
 (but still use LDAP for groups)
  - Write a standalone external plugin, but then do what for Groups?  I
 would be reasonably happy to just have 1:1 mapping of users to groups.

 Does this make sense?

 Thanks

 --
 Kind Regards,
 Daviey Walker

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev