As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.Well that's actually easily answered. If you are a developer who only needs to talk to one type of directory (e.g. Active Directory) and only one instance of it, you SHOULD continue to use your favorite LDAP API (e.g. ADSI).
However, many developers have encountered lots of issues building great inter-operable LDAP applications. Clayton Donley has some good examples here. For many of these developers, virtual directory has been the solution.
Putting the business value question aside (we discussed that in previous posts), the developer audience for the IGF-enabled Attribute Service API is all of the other developers working on applications that don't fit the above criteria (probably about 90%). Up until now, those developers have been stuck building their own "silos" of identity information. After-all if you can't figure out how to plug into an unknown environment, why not create your own?
With the advent of new user-centric protocols, the demand to use Identity Services is growing. But if the LDAP community was bad at tooling, user-centric systems are worse (if only because it is still early days for these protocols). I think the point of having an open source attribute service project is to begin the process of creating an API relevant to applications developers, supports the newer protocols, and most importantly, is worth moving away from the silo architectures of the past and moving towards an Identity Network approach that inherently makes the application better in compelling ways.
Jeff is correct, building this kind of tooling and a community of support is not going to be easy - but we have to start somewhere. To that end, your input is indeed welcomed and wanted! Please check out the IGF Attribute Service project at openLiberty.
2 comments:
Do you see attributes as the same as what Kim Cameron refers to as claims: assertions made by one party about another? If so, do you see the need for/is there the equivalent of a claims transformation service (aka STS) in IGF?
Interesting question! I think claims are a sub-category of attributes that indicate that some asserting authority is making some kind of claim (which might be nothing at all) about the accuracy of the assertion being made.
In contrast, attributes might just be the raw data behind those claims.
I definitely see the need for attribute and claims transformation. In IGF terms an STS would be an "Attribute Authority".
CARML declarations would form part of the WS-SecPolicy that the STS interprets to generate requested claims which may require transformation of attributes etc.
More importantly, the STS needs to decide if the release of assertions is appropriate in the context specified by the CARML declarations. This decision to release information should be based on a XACML policy (AAPML) capable of evaluating the full context of the transaction (which may or may not include all or some of: who was asking, using what application and for what purpose).
Post a Comment