[openstack-dev] [Keystone] Federated Identity Management and user creation
David Chadwick
d.w.chadwick at kent.ac.uk
Thu Jan 31 22:34:29 UTC 2013
On 31/01/2013 20:09, Dolph Mathews wrote:
> I'd be more interested in the impact of not providing a user ID in the
> authentication response at all, but instead having a privileged call in
> keystone to *attempt* to lookup the user associated with a token, if one
> exists.
I am not saying that a keystone user ID should not be there in the
token, but rather that authz should not be based on it, since the id may
be transient. The keystone user ID is probably needed in order to look
up the user in keystone's database.
In an earlier posting (to Matt Joyce on 25 jan) I suggested what the
contents of an extensible keystone token should be, and the user ID was
there.
>
> Swift wouldn't be able to define ACL's by user_id,
that's correct. Because the keystone user_id is not an identity
attribute of the user. Its simply a handle to hang the identity
attributes from, and it might be a transient id.
our 3-step
> authentication flow would have to change (GET /users/{user_id}/projects
> wouldn't be viable for users that don't know their own user_id)... can't
> think of anything else...
>
However the user_id can still be used to pick up the user's identity
(authz) attributes such as projects and roles. So authz can still be
effectively achieved
regards
David
>
> -Dolph
>
>
> On Thu, Jan 31, 2013 at 12:33 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> On 01/31/2013 10:40 AM, David Chadwick wrote:
>
> this is missing the whole point of federation and ABAC. We do
> not want to base access on unique IDs (or the lack of them) but
> rather on the identity attributes that users posses. Your
> proposal would only work if all users from the same IDP had the
> same set of identity attributes. But this is obviously not the case.
>
>
>
> Nope.
>
>
> WHat matters is what is in the token. The User ID is just a
> book-keeping tool in this case.
>
>
>
> As I said in a previous posting, a new way of thinking about
> authz is needed, one that is not based on the unique user IDs
> that Keystone assigns.
>
>
> Think of it his way. If i invite you to the Open Stack table via
> Federation, I am responsible for you. The common userID is the
> account responsible for the actions of the ephemeral users.
>
> The token will have a set of identity attributes in it, signed by
> Keystone. That is all the user needs, not a separate account in
> Keystone's user table.
>
> Another way of saying it is that we already have an ephemeral user
> construct, it is the token.
>
>
>
> For a start, when you first configure your federated OpenStack
> system, there wont be any users in the database and so there
> wont be any unique Keystone user IDs, so services wont be able
> to create ACLs based on them.
>
> Not true. There are mechanisms for pre-populateing the users, part
> of the install system. You don't need to completely pull yourself
> up by your own bootstraps.
>
>
> However, the users *do* exist, and they do have identity
> attributes that will be asserted by the IDPs. So the services
> *can* build their access controls at initialisation time, before
> any users are created in Keystone (I am only taking about end
> users not admin users which will exist). The services do this by
> deciding which keystone attributes (project, roles etc) they
> will give the users in exchange for their IDP asserted
> attributes via the new attribute mapping service we have built.
>
> So when a user does log in, via his IDP, a temporary user entry
> in Keystone is created for the session, his IDP attributes are
> mapped into the correct set of roles and projects (tenants), and
> the service gives the user the correct set of access rights.
> When the session is completed, the user entry will be
> automatically deleted from Keystone.
>
> Its clean and simple. Kristy is already building this
>
> regards
>
> David
>
>
> On 31/01/2013 15:29, Adam Young wrote:
>
> Create a user per federated source. Federated users with no
> unique IDs
> are associated with the common user account. That account
> should be
> able to access the set of all resources that anyone in the
> account can
> have. It should not have a password, and users should not
> be able to
> log in as that Federated user account.
>
>
> On 01/29/2013 07:41 AM, David Chadwick wrote:
>
> Hi Adam
>
> I have addressed auditability in my previous post.
> Misuse can still be
> addressed even with transient IDs and transient users,
> so no further
> comments here on that issue.
>
> In our initial implementation of FIM we did indeed
> create new users in
> Keystone for every new user arriving from an IDP. This
> has two
> negative consequences
>
> a) we cannot deal with users with transient IDs (as can
> be produced by
> Shibboleth) so we have to mandate that permanent IDs are
> used by all
> IDPs (which Shibboleth can do). Still its a (minor)
> limitation.
>
> b) we have a housekeeping problem of knowing when to
> delete old users
> from the user database. In our initial implementation we
> did not
> address this, so the database just keeps on growing
> unless manual
> intervention takes place. This is a tricky problem to
> solve. When
> should an entry be deleted? Time limits is not an
> adequate solution.
> My account at Kent has been active for 8 years and
> growing, whereas
> students accounts are deleted each year. Should the IDP
> notify
> Keystone every time its database is updated? Or
> something else?
>
> So we thought that a better option would be to only hold
> transient
> user entries in Keystone for the duration of the
> validity time of the
> identity assertion from the IdP. This solves the user
> management
> problem, as well as the rights revocation problem, since
> a user now
> only has rights for the duration of his session. (If you
> want active
> revocation in the middle of a session this is a
> different issue.) User
> management is pushed right back to the IDP, which is the
> right place
> for it. The IDP keeps its user database up to date, and
> only current
> users will be given credentials to access Keystone.
>
> As far as I can tell the only negative consequence is on
> a service
> which currently uses the user ID in its access control
> list. Since
> Keystone creates this ID automatically when a user entry
> is created,
> then the same user will have different ID for different
> sessions. So
> the user ID ACL system wont work without either
>
> a) Federated Keystone having a different way of
> assigning unique IDs
> to user entries, so that the IDs can be the same for the
> same user
> even if the entry is deleted then created again, or
> b) services using a different attribute type in their
> ACLs (one that
> still contains a permanent unique ID for the user).
>
> regards
>
> David
>
>
> On 28/01/2013 17:50, Adam Young wrote:
>
> On 01/28/2013 08:20 AM, K.W.S.Siu wrote:
>
> Hello,
>
> When Federated Identity Management is used, the
> authentication
> statement issued by the external Identity
> Provider(s) may contain a
> temporary (or transient) identifier for the user
> rather than a
> permanent (or persistent) one. Because of this,
> it is not possible to
> always uniquely identify the user each time when
> federated
> authentication is used in Keystone (unless one
> of the user's identity
> attributes is globally unique, such as an email
> address). As an
> existing user is required to issue tokens, it is
> necessary to create a
> new user each time authentication takes place
> which could result in
> the backend storage becoming full of redundant
> data. As a solution to
> this, we propose the addition of a validity time
> field in the user
> entity which can be used to remove expired user
> data and allow
> temporary users to be created based on the ID
> provided by the Identity
> Provider. Determining the details of the new
> user account will be done
> by the proposed attribute mapping service.
>
>
> That is a pretty important distinction. It would
> potentially have
> impacts on Auditability. Once you say the user
> object is transient, it
> n longer has an authority to address misuse, at
> which point it falls
> back on the organization that is Federated to
> Keystone. Would it be a
> cleaner solution to link the tokens with a single
> federated account, and
> then to use that account to create all tokens? The
> tokens could have a
> subset of roles and access to a subset of endpoints
> based on the data
> approved by the Federated organization. It would
> just be a metter of
> nailing down how the ephemera ids are issued. I
> would almost want them
> to be stored in a separate table from the users,
> which is what the token
> table already is.
> Is it essential that we modify the user object, or
> are you just
> proposing it as a "path of least resistance?"
>
>
> At the moment we are wondering how people feel
> about this, and if
> anyone has any comments or suggestions.
>
> Many thanks,
> Kristy
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
More information about the OpenStack-dev
mailing list