by Vittorio Bertocci

Summary: Today’s identity-management practices are often apatchwork of partial solutions, which somehow accommodate but never reallyintegrate applications and entities separated by technology and organizationalboundaries. The rise of Software as a Service (SaaS) and cloud computing,however, will force organizations to cross such boundaries so often that ad hocsolutions will simply be untenable. A new approach that tears down identitysilos and supports a de-perimiterized IT by design is in order.

Contents

Introduction
The Sky Is the Limit
Claims-Based Solutions
Basic Definitions
Architectural Patterns of Claims-Aware Solutions
The Canonical Pattern: Subject-IP-RP
The Claims Transformer Variation: Subject-IP-ClaimsTransformer-RP
Delegation
Claims and Cloud
Access Control via Claims Transformation
Externalizing Authorization
Managing Relationships
The Future
Call to Action
Conclusion
Resources

Introduction

This article will walk you through the principles of claims-basedidentity management, a model which addresses both traditional and cloudscenarios with the same efficacy. We will explore the most common token exchangepatterns, highlighting the advantages and opportunities they offer when appliedon cloud computing solutions and generic distributed systems.

The Sky Is the Limit

When you look at a cloudy sky, your inner child probably seesdragons and castles; don’t be surprised if your inner architect, after havingread this article, will see dollar signs. Cloud computing promises to bringradical advantages to the way in which we think of IT: Its basic idea is thatcompanies can host assets outside of their own premises, reaping the benefitsof those assets without the burden of maintaining the necessary infrastructure.This is somewhat similar to the idea of SaaS, where companies can avoid theburden of maintaining on-premise applications that are not specific to theircore business, buying the corresponding functionality as a service. Cloudcomputing, however, pushes the bar further. Instead of buying completeapplications provided by third parties, such as the classic CRM and HRpackages, the cloud offers the possibility of hosting yourown resources in data centers that are exposed to you as a platform. You have all the advantages of retaining controlof the resource, without the pain of CPU and bandwidth usage, dealing with thehardware, cooling the room; you don’t even need to worry about patching yoursystem. If your Web application produces new data every day, using a data storein the cloud saves you from constantly buying hardware for accommodatinggrowth. The best part is that you can expect to be charged an amountproportional to the usage you actually make of the resource, instead of havingto invest in hardware and infrastructure beforehand. This “pay-per-use” patternis one of the reasons for you will often hear the term “utility computing”instead of “cloud computing,” and it is even more evident in CPU-intensivetasks. Imagine if, instead of sizing your data center for handling its maximumforecasted peek and underutilizing it most of the time, you could deploy yourmost CPU-hungry processes in a data center of monstrous proportions: The CPUutilization could grow as much as requested, and you would pay your cloudprovider in proportion. Those are some of the advantages that will light asparkle in the eyes of your IT managers, but the Cloud holds even moreinteresting properties for architects. Since the cloud provider hosts resourceson a common infrastructure, it is in the position of offering services that canbe leveraged by every resource simplifying development and maintenance. Obviouscandidates are naming, message dispatching, logging, and access control. Once aresource uses the cloud infrastructure, implementing those functionalities canbe factored out from the resource itself.

The literature on cloud computing is vast and grows every day: Ifthe introduction above was not enough to convince you of its disruptivepotential, simply search for the term with your favorite search engine to get afeeling of how seriously the industry is taking it. The diligent architect, atthis point, is likely to wonder, “Is my company ready for this?” Notsurprisingly, answering this question is a complex task and requiresconsidering many aspects of your architecture and your practices. In extremesimplification: If you run your business according to solid service orientation(SO) principles, you are in the ideal position to take advantage of the newwave. After all, if you respected autonomy, exposed policies, and usedstandards, who cares where your services run? If you are in that position, youhave my congratulations. In my experience, however, nobody ever applies SOprinciples in excruciating detail. For example, services developed with thesame technology offer special features when talking with each other, and thereare situations in which it makes perfect sense to take advantage of those.

Identity management and access control are most likely to beaffected by this phenomenon. Enterprises typically have their directorysoftware, and they rightfully leverage that for many aspects of the resourceaccess control; sometimes it works so well that developers are not exposed toidentity concepts, which is actually a good thing, but that rarely happens.When faced with tasks involving some form of access control management, such asfederating with partners outside the directory or using different credentialtypes, you can expect developers to come out with the worst swivel chairintegration solutions. If identity brings out the worst from developmentpractices, why do we get away with it? The easy answer is that sometimes wedon’t. I am sure you have heard your share of horror stories of access controlgone wrong. The subtler answer is that we get away with it because, until weown the majority of the infrastructure, if we exercise iron-fist governance, wecan somehow handle it: We may use more resources than needed, we may deal withemergencies more often than needed, but somehow we go on. In fact, “we own themajority of the infrastructure” is a fact that is challenged by growing marketpressure. When a lot of your business requires you to continuously connect andonboard new partners, where does your infrastructure end and theirs begin?Cloud computing is going to snowball this: Once the cloud is just anotherdeployment option, crafting custom access code for every resource will simplybe not sustainable.

The good news is that there is an architectural approach that canhelp manage identities and access control for generic distributed systems, andit works for on premise, cloud, and hybrid systems alike. The core idea is modelingalmost everything as exchanges of claims, and model transactions in a much morenatural fashion.

This article is an introduction to this new approach. Specialattention will be given to the aspects that are especially relevant for thecloud, but the vast majority of the concepts and patterns presented can beapplied regardless of the nature of the distributed system. Note that theproblems we are trying to tackle here are not just the simple single-site,membership provider-based application. While the principles laid down hereapply to any system, hence also to simple cases, their expressive power is bestutilized for scenarios including partnerships, complex access rules, andstructured identity information.

If the following definitions are hard to digest at first, thinkof how difficult it must have been to learn to use the digit "0" forthe Europeans of the Middle Ages, used to sum up numbers using the Romannotation. In that case, there was an established practice to go against, but thepayoff of adopting a better model was exceptional!

Claims-Based Solutions

The issue with classic identity-management solutions can besummarized as follows: They presume too much.

The most common assumption is that every entity participating ina transaction is well known by some central, omnipresent authority that candecide who can access what, and it what terms. This is usually true inself-contained systems, such as enterprise networks managed via directories,but fails when business processes begin to require alien participant such assoftware packages with their own identity stores, partners and customersaccessing your extranet, and consultants. Tactical solutions, like using shadowaccounts, often have to do with pretending to be able to manage something we don’town; and as such, they are very brittle.

Another common assumption is that every participant in atransaction uses a consistent identity-management technology. Again, this is afair assumption for self-contained systems (think network software), but itfails as soon as you let aliens in the process. The common practice inaccommodating different technologies is treating those cases as exceptions. Asa result, the resources themselves end up embedding a lot ofidentity-management plumbing code, written by developers that usually are allbut identity experts. This is every bit as bad as the old taboo for embeddingbusiness logic in the presentation layer, perhaps even worse. Handling identityplumbing directly inside the resource not only makes the system brittle andhard to maintain, it also makes the life of system administrators miserable.How can you manage access control at deployment time if the logic is lockedinside the resource itself?

The claims-based approach defuses these issues by assigning eachtask to the entities who are its natural owners, and avoiding introducingartificial dependencies and expectations by respecting the autonomy of allparticipants – nothing but good old SO architectural principles.

To follow, I will give a quick description of the claims-basedapproach. The topic in itself is huge; in fact, I coauthored a book on thesubject. In order to fully understand the implications in this article, Irecommend reading Chapter 2, freely available online on MSDN (see Resources).

Basic Definitions

Here I will present a bestiary of the various concepts andconstructs you will encounter while exploring claims-based approaches.

Claims

A claim is a fact about an entity (the “subject”), stated by another entity (the “authority”).

A claim can be literally anything that describes one aspect of asubject, be it an actual person or an abstract resource. Classic examples ofclaims are “Bob is older than 21,” “Bob is in the group "remotedebuggers" for the domain Contoso.com”, and “Bob is a Silver Elite memberwith one Star Alliance airline. A claim is endorsed by an authority; hence oneobserver can decide if the fact the claim represents should be considered trueaccording to the authority’s trustworthiness.

Trust

An entity A is said to trust an entityB if A will consider true the claims issued by B.While very simplistic, this definition serves our purposes here. Trusting whatB says about a subject saves A from the hassle of verifying the claim directly.Entity A still needs to make sure that the claim is actually coming from B andnot a forgery.

Tokens

A security token is an XML construct signed byan authority, containing claims and (possibly) credentials information.

Security tokens are artifacts, XML fragments described in (see Resources:WS-Security), which can fulfill two distinct functions:

·        theyprovide a means to propagate claims

·        theycan support cryptographic operations and/or have a part in credentialsauthentication

Thanks to the properties of asymmetric cryptography, the factthat a token is signed makes it easy to verify the source of the claims itcontains.

Tokens can also contain cryptographic material, such as keys andreferences to keys, which can be referenced in encryption and signatures inSOAP messages; those operations can be used as part of credentials verificationprocesses. In this context, we consider a “credential” any material that can beused as part of some mechanism for verifying that the caller is a returninguser: Passwords and certificates are good examples (for more details, seeResources: Vittorio Bertocci’s blog, The Tao of Authentication).

Tokens can be “projections” of specific authenticationtechnologies, such as X509 certificates, or they can be issued (SAML, a populartoken format you may have heard mentioned in the context of Web servicessecurity, is one example of an issued token). The system is future-proof: Asnew technologies emerge, suitable token “projections” can be documented inprofile specifications.

Security Token Services (STS)

A Security Token Service is a Web service thatissues security tokens as described by WS-Trust (see Resources:WS-Trust).

An STS (see Figure 1) can process requests for security token(RST) messages and issue tokens via requests for security token responses(RSTR). Processing the RST usually entails authenticating the caller andissuing a token that contains claims describing the caller itself. In somecases, the STS will issue claims that are the result of transformations ofclaims it received in the RST. (For more details, see Resources: VittorioBertocci’s blog, R-STS.)

Figure 1. Anatomy of a security token

The Identity Metasystem (IdM)

The Identity Metasystem (IdM) is a model thatprovides a technology agnostic abstraction layer for obtaining claims.

This is a very simplified definition that does not render justiceto the model; for example, it does not mention policy distribution and systemsmanagement. (See Resources: WS-Security, WS-Trust.)

Every identity technology tends to accomplish the same tasks,following common patterns and dealing with more or less the same functionalroles. The IdM describes those patterns and roles in an abstract fashion,modeling the behavior of any system in term of claims exchanges but leaving thedetails on how those are implemented to the specific technologies. Thenecessary level of abstraction is achieved by taking advantage of open, interoperableprotocols such as the WS-* family of specifications.

The IdM describes three roles:

·        Subject.The subject is the subject entity we mentioned in the claim definition. It iswhoever (or whatever) needs to be identified in a transaction.

·        Relyingparty (RP). The RP is the resource that requires authentication before beingaccessed. Examples of RPs include Web sites and Web services. RPs derive theirname from the fact that they rely on IPs for obtaining claims about the subjectthey need to identify.

·        Identityprovider (IP). The IP is the authority entity we mentioned in the claimdefinition. An IP possesses knowledge about the subject, and can express it inthe form of claims: Any RP that trusts that particular IP will be able to relyon those claims for making authentication and authorization decisions onsubjects. Note: Often the IP will use an STS for issuing claims in the form oftokens; that does not mean that every STS is an IP. An STS is a tool that theIP uses to get its job done.

Architectural Patterns of Claims-Aware Solutions

The basic aforementioned concepts constitute the basis for a newphysic of authentication, and as such they can be combined to describe anysystem and transaction. In this new world, we can finally separate twofunctions traditionally conflated into one: obtaining information about thecaller (via claims) and verifying if it is a returning user (via credentials).Thanks to this separation, we can now choose which function fits best ourscenario; for more details see Resources: Vittorio Bertocci’s blog The TAO ofAuthentication.

There are certain patterns that are especially useful fordescribing common scenarios. To follow, I will describe the three most commonof those patterns, along with some of the advantages that the claims-basedapproach brings to those scenarios with respect to traditional practices. Allthe patterns are suitable both for on premise and cloud architectures.

The Canonical Pattern: Subject-IP-RP

This pattern describes the minimal situation in authenticationmanagement: a subject wants to access a restricted resource (the RP). Thishappens when a Windows user tries to access a network share, when a smartclient invokes a secure Web service, when a Web surfer wants to browse restrictedcontent, you name it (see Figure 2).The key steps are as follow:

Figure 2. The Subject-IP-RP canonical pattern. The numbersrefer to the text.

1.     (out of band) The RP publishes its requirements in the form of a policy.Those requirements include

     a.     A list of claims

     b.     The IPs that the RP trusts as sources of those claims

     c.     Details about the specific authentication technologies that the RP canuse; for example, the token formats that the RP understands

2.     The subject reads the RP policy and verifies whether it can comply withit. In practice, it means verifying if the subject can obtain a suitable tokenfrom any of the IPs that RP trusts.

3.     The subject invokes a suitable IP, requesting a token that complies withRP policies. In practice, it usually means sending an RST message to the IP’sSTS.

4.     The IP receives the RST and authenticates the subject. If the subject isknown, the IP will retrieve the required claim values, package it in a token,sign it, and send it back to the subject.

5.     The subject receives the token and uses it for invoking RP.

6.     RP extracts the token from the invocation message and examines it: Is itsigned by one trusted IP? Does it contain the right claims? If the check ispositive,

     a.     the claims values are used for feeding some access control logic

     b.     If the access control logic is satisfied, the claim values are madeavailable to the resource itself and access is granted

For the purposes of this explanation, let’s assume that theresource is a Web service. The pattern above exhibits many good properties.

Authentication Externalization

Using tokens and claims lifts from the resource the burden ofwriting any explicit identity-management code. The same infrastructure thattakes care of publishing RP policies can also perform operations such asdeserializing tokens, checking signatures, and making claims values readilyavailable to the resource developer regardless of the token format that wasactually used on the wire. The infrastructure can also perform someauthorization decision based on claims values, reducing further the tasks thatthe developer needs to worry about.

This is an advantage that holds for any scenario, but especiallyfor the cloud where the hosting technology is one of the variables. Usingclaims makes resources truly portable, by decoupling them from the details ofthe infrastructure that will host them and the authentication technology thatwill be available at runtime.

Resource-Level Policy

Being able to specify policies at the resource level allows forvery agile deployments, fine-grained control, and dynamic negotiation of theauthentication technology of choice. It allows for establishing a managementstrategy that will work regardless of the hosting environment, thanks to theuse of interoperable standards. It decouples the resource itself from theexecution environment, making it much easier to move the resource around(including to the cloud).

Autonomy

Every resource specifies its requirements in an autonomousfashion: It is the subject that matches those with its own capabilities. Theinteraction is an emergent property of the combination of the two. Both partiescan change independently, and the set of subjects that can access the resourceis defined solely by the ability to comply with the requirements as opposed tosome out of band or infrastructural dependency. The system is very robust,since everybody needs to worry only about its own requirements andcapabilities. Onboarding users is very easy, since it does not require anyexplicit negotiation or arrangement.

Centralization of Some Authentication and Authorization Logic

In this pattern, the IP performs all the attributes retrieval.The RP receives what it needs in the form of a token, without needing to queryother systems. This is obviously an advantage for those attributes to which theRP would not have access (i.e., Airline A asks for the subject’s frequent flyerstatus with partner Airline B), but it is also a great means of centralizingattribute retrieval logic in a single place. Not only does it reduce the numberof endpoints that need access to attribute stores, with advantages formanageability and security, it can also reduce the number of accesses itself,since once the subject obtains a token it can cache and reuse it until itexpires without getting back to the IP. The IP can also be used forauthorization decisions, which can be expressed via claims as well; however,this can happen only when the IP has a tight relationship both with the subjectand the resource. While this happens in important scenarios, such as when theIP represents a directory and the RP is one of the resources it manages, in thegeneric case no relationship can be assumed between RP and IP.

This is key to many cloud scenarios, in which resources need torely on external IPs for verifying information about possible users; however,it is also very useful in more agile versions of classic federation, in whichusers of a partner organization can be represented by technology- andplatform-agnostic tokens, and for crossing boundaries of any kind.

The Claims Transformer Variation: Subject-IP-ClaimsTransformer-RP

The pattern just described can be applied to a wide range ofscenarios, from consumer (frequent flyer with Airline A accessing the Web siteof partner Airline B) to enterprise (almost any Kerberos scenario can bemodeled that way, with the added bonus of technology independence).

However, there are situations in which certain constraints mayprevent the application of the pattern as it is:

1.     Indirect trust—A RP may not directly trust theIPs that are in a relationship with the subject, but there could be a chain ofintermediate authorities that can be traversed for brokering trust. If you wantto board a plane, you won’t be able to do so using just the documents alreadyin your wallet; the employee at the gate will trust only a boarding pass issuedby the proper airline. However, you can use the documents already in yourpossession (passport or driver’s license, issued by the government) at thecheck-in counter to obtain the boarding pass (issued by the airline).

2.     Claims format—The RP may not be able tounderstand the claims in the format issued by the IPs that are directlyavailable to the subject. Sometimes it is a simple matter of format (my ItalianID says “nato il” instead of “birth date,” a bartender in the U.S. would not beable to extract the information he needs even if it’s there), other times theclaims required by the RP are the results of some processing of the rawinformation received (the RP may need a “CanDrink?” claim, which may be theresult of processing “age” and “Nationality”).

The new constraints can be easily addressed by adding a newelement, which we will call a claim transformer, that can process a tokenbefore it reaches the resource and can be leveraged by the RP to broker trustand convert the incoming claims in a more suitable format. Between the subjectand the RP, there could be an arbitrarily long chain of claim transformers.Dynamic negotiation of policy can automatically “choose” a path, if available,without any need to plan it at a high level.

The best artifact for implementing a claim transformer is, again,the STS. Instead of populating the issued claims from its own data sources, theSTS used by the claim transformer will mainly manipulate the incoming information.Since it is often run by the same entity that owns the RP, as in the classicfederation case, this kind of STS is usually referred to as Resource STS, R-STSor RP-STS. I recommend reading my blog for more details (see Resources).

This variant presents some powerful advantages and, in ouropinion, will emerge as the dominant pattern for identity management indistributed systems (see Figure 3).

Figure 3. Basic claims transformer pattern. The Subject (1)obtains a token from the IP and (2) uses it to get a token from the claimstransformer. The R-STS of the claims transformer processes the incoming claimsand (3) issues the subject a new token. The subject (4) uses the new token toinvoke the resource.

Resource Clustering

Claims transformers can offer a granularity continuum betweensingle resources and the directory at the enterprise level. An R-STS can beused for corralling multiple resources with similar requirements. It simplifiesthe policy management of single resources, moving the complexity of brokeringtrust and processing raw claims in a single point but without requiring it atthe enterprise level. An R-STS can be a virtual boundary protecting legacyresources that may not play too well with the rest of the network. Those arejust few examples of the expressive power of claims transformers (see Figure4).

Figure 4. R-STSes can be used to cluster multiple resourceswith similar policy requirements, simplifying trust management and providing ameans to control the granularity of externalized authentication and authorizationlogic.

Authorization Decision Point

While an IP is usually an independent entity, very often theR-STS has some knowledge of the resources it fronts. Such knowledge may enablethe R-STS to perform authorization decisions. The incoming claims can beprocessed together with the requirements of the resource the subject is tryingto access, and the result may be a decision about whether the subject holds thenecessary privileges. Such a decision can be expressed in different ways:

·        Ifthe subject does not hold any privileges, the R-STS may simply refuse to issuea token and block the invocation. In this case, it would enforce authorization.

·        Ifthe subject holds some privileges, the R-STS may formalize those authorizationdecisions in the form of claims. The RP is hence relieved from the need to runauthorization logic, and will just enforce the directives it receives from theR-STS in the form of claims.

The use of tokens, claims, and IPs made authenticationexternalization possible; the R-STS can, in certain cases, help to do the samewith authorization decisions.

Delegation

There are many resources that are not claims-aware: legacysystems, resources managed directly at the directory level, and so on. Oftensome investments have been already made to manage access to those resources,such as assigning ACLs and creating groups. The identity of a subject calling afront-end application via claims-based security would not be suitable toleverage those investments; if the front-end application could obtain adirectory identity on behalf of the caller, however, the problem would besolved. In fact, the value of obtaining tokens on behalf of somebody else isclear even when the issued tokens remain in the realm of claims.

Claims and Cloud

The beauty of what I’ve described so far is that it adapts to anyloosely connected system; and what is the cloud, if not the ultimatedistributed system? When you reason at cloud scale, you deal with a world whereevery entity is managed independently: claims, tokens, trust, and identitymetasystem roles can help you make the best of whatever little information youmay have about the relationships among the parties you deal with. By describinga claims-based solution, we killed two birds with one stone, giving you toolsthat can be applied on premise and on the cloud alike.

We still know too little of how things will evolve to givedetailed guidance on cloud scenarios. However, with some working hypothesis, wecan certainly highlight the aspects of claim aware identity management that areespecially well suited for the cloud.

Access Control via Claims Transformation

We have seen that a cloud provider may offer services such asstorage and compute, messaging, and integration. If you recall what wedescribed in the claims transformer section, you will see that an obviousaccess control strategy for the cloud provider is to offer an R-STS and havethe resources trust it. Every tenant would then be able to govern accesscontrol simply by manipulating the claim transformation rules of the R-STS.

Let’s say that you are an ISV, and you want to deploy yourservices at a certain cloud provider. You decide on the set of claims yourservices will accept, and you set your services to trust the provider’s R-STS.Your access control strategy is already in place, regardless of who calls yourservices! When onboarding a new customer, you simply have to define how to maphis claims to yours, by setting some rules at the R-STS level. This can beincredibly agile and easy to maintain (see Figure 5).

Figure 5. An R-STS in the cloud is a very powerful tool formanaging access control. The resource always handles tokens and claims in theright format, from the same trusted source; the R-STS takes care of handlingtrust management and credential verification from different sources, usingrules to perform the necessary transformations and isolating the resource fromchanges and unnecessary complexity.

Externalizing Authorization

We have seen how an R-STS can conveniently externalize andaggregate authorization decisions; this is, of course, valid in cloud scenariosas well. In fact, there are cases in which this can be pushed further toinclude authorization enforcement. Getting back to the ISV example:

If the services are exposed by taking advantage of some messagingoffering, the dispatch infrastructure itself can take care of enforcingauthorization decisions by examining the authorization claims even before themessage is routed to its destination. This relieves the ISV from yet anotherburden: If the services are not exposed using the provider’s messaginginfrastructure, the authorization decision claims have to be enforced by addingsome processing pipeline in front of the resource. (For more details, seeResources: Vittorio Bertocci’s blog, claims types.)

Managing Relationships

With the model described, an ISV can represent a customerrelationship as a set of rules. This is much more agile than creating afederation relationship by traditional means, directory to directory. Whilecoarser to manage, it also avoids the burden of extra management that isnecessary in peer partners relations but would often be overkill for vendor-customerrelationships.

The model also allows for accommodating individuals and customerswithout advanced identity capabilities. The ISV services will always see tokensissued by the R-STS, regardless of whether the customer authenticated with a tokenissued from his own IP or with simple, one-off username and password.

The Future

The shift toward the cloud will happen: the industry is fairlyquick to acknowledge that it is not a matter of if, but when. Predicting thefuture is always a dangerous game, but the cloud is just too exciting for notventuring in a plausible development that, despite looking like an identityutopia today, is in fact perfectly plausible thanks to principlesdescribed so far.

Today, access control is often constrained in the railways oforganization structure, with privileges reflecting rank rather than function.The number and the caliber of companies and open-source initiativesparticipating in interop events (see Resources: RSA 2008 OSIS Interop event)and integrating support for claims in their lead products suggests thatclaims-based programming is on its way to becoming mainstream. Once thathappens, it is easy to imagine how identities and access control structures maybe corralled around tasks rather than organizations. Subject, resources, roles,and authorities from many different companies could all be described in termsof a specific project, with privileges assigned not according to organizationrank but reflecting the function performed in the context of the projectitself. Virtual organizations could emerge for the duration of the task, anddissolve once the mission is performed. That would also allow for templating ofcross companies efforts, enforcing best practices and improving predictability(see Figure 6).

Figure 6. Policies, claims exchanges, and virtual directorymanagement make possible the semi-spontaneous emergence of virtualorganizations (center).

For this to happen, claims are a necessary, but not sufficient,condition: Emerging technologies such as virtual directories will play a keyrole as well (see Kim Cameron’s blog, www.identityblog.com, for more details).

Call to Action

The claims-based approach is great for traditional and cloudscenarios alike. The difference is that while in traditional scenarios you cansometimes use a great deal of extra resources to get away with bad strategies,once the cloud is upon us, it won’t be that easy. If you want to prepareyourself and your organization for the upcoming wave, here there are somethings you can do:

·        Experimentwith Web services and security, if you are not already doing it

·        Experimentwith claims-based programming, taking advantage of the Beta release of “Zermatt”Developer Identity Framework (http://go.microsoft.com/fwlink/?LinkId=122266)

·        Considerrunning pilots within your organizations. For example: create an IP for youremployees

Conclusion

Here I could offer the proverbial “we barely scratched thesurface of the topic,” and that would be true. Instead, I will say that claimsare the cornerstone of exciting developments in identity management fortraditional and cloud scenarios alike. I invite the geeks among you to enjoythis special transition moment in which much of those interactions are stillevident, and I reassure all the others by foreseeing that most of the detailswill likely sink in the infrastructure and be made invisible by new breeds oftools.

Resources

Vittorio Bertocci’s blog:

·        “R-STS”:http://blogs.msdn.com/vbertocci/archive/2007/09/24/the-resource-sts-r-sts-rp-sts-a-sts-the-other-face-of-token-issuing.aspx

·        “claimstypes”: http://blogs.msdn.com/vbertocci/archive/2008/05/05/claim-types-a-coarse-taxonomy.aspx

·        “TheTao of Authentication” I, II and III:

http://blogs.msdn.com/vbertocci/archive/2008/02/20/the-tao-of-authentication-part-i.aspx

http://blogs.msdn.com/vbertocci/archive/2008/03/10/the-tao-of-authentication-part-ii.aspx

http://blogs.msdn.com/vbertocci/archive/2008/03/11/the-tao-of-authentication-part-iii-last.aspx

Kim Cameron’s blog:

·        “virtualdirectories”: http://www.identityblog.com/?p=983

“Understanding Windows Cardspace”, Chapter II (Addison Wesley2008), on MSDN

http://download.microsoft.com/download/d/3/9/d399b17c-0958-49b7-8559-bea1956c2c5b/0321496841_02.pdf

RSA2008 OSIS Interop event:

·        logos:http://web3id.org/files/RSA2008 Handout/I3-Handout.jpg

·        OSISinterop: http://osis.idcommons.net/wiki/Main_Page

WS-Security

http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

WS-Trust:

http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf

About the author

Vittorio Bertocci, senior architect evangelist, Cloud ServicesEvangelism, Microsoft Corp., helps large enterprises leverage new technologies.After a few years in the Italian Microsoft Services, he moved to the U.S.headquarters, where he has spent the past three years helping customers deploysolutions based on identity and access management, SOA, and services. Hecurrently focuses on the identity and access aspects of cloud computing;Understanding Windows Cardspace, the book on user-centered identity hecoauthored, was published last January. Vittorio maintains a popular blog at http://blogs.msdn.com/vbertocci.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the ArchitectureJournal Web site.