MSDN Magazine - January 2009 - (Page 73)

IP-STS, each evaluating to a set of claims representative of the credential. Joe The IP-STS transforms these claims into a normalized set of application 4 Client claims that the RP relies on to authorize Read( ) Authenticate calls—which can be roles or more granular claims such as create, read, update, Authorize Read( ) RP 7 or delete rights. The diagram in Figure 12 illustrates such a scenario where the 3 Admin user logs in and is granted a Role 7 1 claim and several Action claims includ5 Issue Authenticate ing Create, Read, Update, and Delete. Token This type of claims transformation Trust is useful in that authentication to an RP-STS IP-STS STS results in a token carrying all of Identity = Joe Name=Joe the claims granted to the user. There Name=Joe Name=Joe Name=Joe RPClaim=GuestRole are cases where an alternate approach RPClaim=GuestRole Role=Guest to claims transformation would be Action=Read 6 2 Transform Claims Transform Claims necessary; for example, to reduce the claims issued to those relevant only for the current call context; to protect the Policy Policy Engine Engine privacy of claims; or to facilitate federation across domains. It isn’t always desirable or appropriate Figure 14 Claims Transformation in a Federated Scenario to grant an authenticated caller a long list of claims related to all features exposed by the RP. Not only could the be responsible for transforming another trusted set of claims into list be very long, but it is also possible that the claims to be granted claims that are understood in the RPs domain. depend on the call context and thus should not be issued without that Figure 14 illustrates this scenario. When Joe tries to access the context. For example, a user may only be granted the Delete claim if RP without a token, he will log in at the IP-STS in his own domain she is interacting with customer orders, but if she is interacting di- (Domain B). The request will ask for claims that the RP understands, rectly with customer records, she may not be granted that right. in this case RPClaim, so that the IP-STS knows to issue a token that In cases such as this one, it can be useful for the RP to request the RP can use. When the RP-STS receives this token it transforms only a few claims from the IP-STS in order to identify the caller, the claims into RP-specific claims. For this federated scenario to and then request a new token with a specific set of additional claims work, there must be trust between the RP-STS and the IP-STS, and only for the context of the call. For example, if the user is invoking they must agree on a set of claims that the IP-STS should issue for the DeleteCustomer operation on an RP service, prior to authoriz- its users that are to be granted access to the RP. ing access to the operation the RP calls to the RP-STS passing in the token from the IP-STS, requesting the Delete claim in the context Wrap-Up of the DeleteCustomer operation. If the claim is present, the call is The Geneva Framework is a very welcome utility for those inauthorized. The diagram in Figure 13 illustrates this example. terested in building a custom STS and who do not need a fully There are also cases where the claims issued by an STS should not featured STS platform such as Geneva Server. Building a custom be shared with the RP directly. For example, rather than issuing an STS is not a trivial task, even with the Geneva Framework, and it Age claim so that the RP knows the user’s age, the RP can request is always recommended that you use a fully featured STS if posthe IsOver13 claim to ensure that the caller is old enough to use RP sible to reduce exposure. functionality. Thus, the actual value for the Age claim never leaves Regardless of the platform, the flow of communication for active the STS. Of course, this implies that the ST supplies claims that avoid and passive STS implementations remains the same, as do the ideas sharing personal details and yet still include data useful to the RP. behind claims transformation. Some additional concepts related Claims transformations also take place in a federated scenario to STS implementations include identity delegation and step-up where users belonging to one domain are granted access to an RP in authentication. You can access samples and documentation related another domain. In this case there are two STS involved—the user to these and other concepts in the Geneva Framework SDK.  domain’s IP-STS and the RP-STS for the domain that owns the RP. Michele leroux BustaMante is Chief Architect of IDesign Inc., Microsoft ReAnd also in this case, IP-STS will grant some agreed-upon claims gional Director for San Diego, and a Microsoft MVP for Connected Systems. Her that RP-STS can understand; however, those claims are not likely to latest book is Learning WCF. Reach her at mlb@idesign.net or visit idesign.net. be directly useful in the RP application. Instead, the RP-STS would Michele blogs at dasblonde.net. msdnmagazine.com January 2009 73 http://www.idesign.net http://www.dasblonde.net http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.