There are two IAM concepts that I really like:
- Identity 2.0, where I can login to a service provider using an identity that was provided to me by an identity provider, who proofs that it is really me.
- Attribute Based Access Control (link to the NIST ABAC standard): you get authorizations not based on your identity, but on your capabilities that some authority feels you have.
The first development makes it possible to separate responsibilities
for objects on the internet. A service provider only needs to take
care of services and data, an Identity Provider (IdP) only has to
take care of digital identities and authenticating it's users. A
service provider only needs to trust the digital identities provided
by an Identity Provider, and that creates an enormous scalability of
web services.
Attribute Based Access Control enables the authorizing of persons as
requested by a process owner or data owner. This owner has to define
the quality requirements for executing tasks within a process of
towards a data element.
The process owner or data owner doesn't need to have any knowledge
about the identities or roles or groups that are defined within an
organization. But this is a new concept and a very tough
responsibility: these owners never before had to think about these
requirements. Nevertheless, this is an exciting concept: someone
doesn't get permissions because of his function or role within an
organization, but because of his capabilities. And these capabilities
are called 'attributes' of the identity.
The interesting thought is that an identity provider also provides
some attributes. Such as address, phone number, gender, date of
birth, expiration date and a lot of other variables. The IdP concept
of ABAC is implemented in the SAML message format, where the term
Claim component is used as the attribute component.
One of these attributes could well be the Role of an identity. An internal identity provider in an organization may well know the function type or role of an employee, who gets a business identity. In such a case an attribute can be used to allow Role Based Access Control capabilities to the access control mechanism.
But... what if a process owner requires an attribute outside of the
scope of the identity provider? Where does the extra attribute come
from? In the ABAC concepts attributes are bound to identities, that
means that in order for an employee to prove that he has the extra
required attribute, he in fact needs to provide another identity that
does contain the required attribute. But... in all reality, that's
just not feasible. What might be possible is that the identity
provider forwards the attributes provided to an identity on behalf of
another identity provider. For instance: an internal IdP could add
attributes, like results from a course that the user attended. But
that creates new trust issues (did the user follow the course
successfully, is the attribute really provided by the school, in what
context can the attribute be used and some more).
I am not aware of any implementation. And perhaps we should not want
such an implementation and we should think of another way.
As a user I would not like this hassle of using different identities
or of 'IdP-in-the-Middle' constructs. I want a convenient place to
store my attributes, some kind of a wallet. Not a wallet with
different identities (although I really loved the Information Cardmetaphor promoted by Kim Cameron), but a wallet with different attributes. And
the attributes within this store could be used with any of my
identities that I want to use for a specific purpose.
I need a PAL, a Personal Attribute Locker, or a PASS, a Personal
Attribute Storage System (I'm great with acronyms :) ). Identity
Providers could post digital identities and/or attributes to my
locker and I could mix and match whatever combinations of identities
and attributes I would want to use. Provided that the context and
scope of identity and attribute is a valid combination, but we'll
have to think about this in another post. What would the implication
be? Suppose I am an employee who needs access to the CRM system. But
in order to execute some CRM task, I would have to provide an
attribute that I am an experienced blog poster. This attribute cannot
be provided by the company I work for, but it can be provided by
Google because of this blog. Google could post this
attribute to my PAL and I could use this 'external' attribute with my
company Identity to execute the CRM task.
What do you think? Is this a feasible idea?
In a future post I will expand on this idea, because recently I found
out about an interesting standard that could perhaps be used as the
mechanism that I want...
2 opmerkingen:
Yes, it would be great to have a central repository of attributes a user (consumer) manages. It is even more important in b2c scenarios. In b2b or enterprise, it is enough that an administrator be able to manage attribute sources.
What would also be interesting is to define rich semantics around attributes.
Thanks for your reaction. I will try to expand on the example in the next post, about the badges, to try to get more understanding of the meaning of attributes. And perhaps your question can be addressed as well, at least I will try to :)
Een reactie posten