The guide works progressively, with the simplest and most common scenarios explained first. It also contains a clear overview of the main concepts. Working source code for all of the examples can be found online (http://claimsid.codeplex.com).This guide is well written with liberal doses of persona-based commentary, great examples and code samples. It’s worth reading this guide to understand the Microsoft lingo and slant on claims and authentication in Microsoft’s web services world.
<!-- RANT ON -->
I am; however, going to single out a particular persona comment that gives me concern:
When you decide what kinds of claims to issue, ask yourself how hard is it to convince the IT department to extend the Active Directory schema. They have good reasons for staying with what they already have. If they’re reluctant now, claims aren’t going to change that. Keep this in mind when you choose which attributes to use as claims.Is the Active Directory schema still the tail that’s wagging the dog after 10 years?! Honestly, how can we progress if this will be the attitude of our IT departments? Maybe “Next Generation Active Directory” (NGAD) will solve the schema problem. Clearly, if I am developing a claims-aware application I need to be able to leverage Active Directory easily otherwise I’ll be looking for another directory to use – or a new IT department.
<!—RANT OFF –>
This guide is an excellent read.
Technorati Tags: Active Directory,ADFS,claims,identity management,authentication,authorization,Microsoft,MSFT,NGAD
3 comments:
Hi Jackson,
I'm afraid I have to agree with the document. If you claims-enable an AD attribute, and that attribute is populated for everyone in the enterprise, then that claim will be in everyone's TGT regardless of whether they need it or not. I can see how this could add up over time.
In a time when lots of enterprises are concerned about token bloat, and the addition of several claims types for one customer will affect everyone's TGT, yeah I do expect IT to look very carefully at the request much as they might a schema request.
When I was at Intel and a newer version of SharePoint came out that required distribution lists to be promoted to security groups, you can bet we looked closely at it - and stalled, because it would have added 18,000 security groups to AD at one stroke and bumped up everyone's token size.
Hi Jackson,
I'm afraid I have to agree with the document. If you claims-enable an AD attribute, and that attribute is populated for everyone in the enterprise, then that claim will be in everyone's TGT regardless of whether they need it or not. I can see how this could add up over time.
In a time when lots of enterprises are concerned about token bloat, and the addition of several claims types for one customer will affect everyone's TGT, yeah I do expect IT to look very carefully at the request much as they might a schema request.
When I was at Intel and a newer version of SharePoint came out that required distribution lists to be promoted to security groups, you can bet we looked closely at it - and stalled, because it would have added 18,000 security groups to AD at one stroke and bumped up everyone's token size.
-Sean
(FWIW, adding a comment here if you aren't in google+ is torture.)
I've been doing some more reading and thinking since I first read your post, and I'm happy to amend my opinion some.
If the claims-aware application uses claim types for attributes no one else uses for anything, and those attributes are populated for just the application's users, then it won't affect anyone else because AD won't do anything with null attributes.
Of course, the other side of the coin is that AD doesn't just keep a ton of use-as-you-please attributes lying around. So, you're probably looking at a schema update anyway to add the 3rd party's required / recommended attribute classes, or a bunch of general-purpose attributes.
Post a Comment