by Gerrit J. van der Geest and Carmen de Ruijter Korver

Summary: In the past, systems were used by a small set ofusers, mostly within the trusted circle of their organization. The circle oftrust, however, has widened considerably. Today’s computer systems are used bya variety of users across many organizations and geographical areas, and viadifferent channels. Organizations must make their information assets availableto many users, but simultaneously protect these against unauthorized access.However, each transaction that is used to access those information assetsshould bear just the appropriate level of access control—not too little in viewof the security risks, and not too much in view of user friendliness and highcosts. How can we achieve an optimal balance between availability andprotection?

Contents

Introduction
Challenges
Trust, Trust, Trust...
Does Absolute Trust Exist?
Trust Model
Associating Value/Risk Transaction Levels with the ParameterLevels
Trust Level Upgrades and Downgrades
Implementation
Conclusion
Resources

Introduction

The answer lies in the management of identity trust. We need tobe able to create, maintain, and communicate various levels of trust. When wecan manage identity trust effectively, we can subsequently tune the level ofappropriate access control to the level of value or risk that is associatedwith the transactions (see Figure 1). Therefore, an organization should ensurethat its strategic Identity and Access Management (IAM) architecture providesfor mechanisms to capture and transport identity trust throughout the servicelayers within its IT infrastructure.

Figure 1. Identity Trust Management

This article describes the management of identity trust asdefined in an IAM reference architecture. It supports an organization’sbusiness requirements, which can range from providing low-threshold access forregistration to performing high-risk financial transactions for high volumes ofconsumers. We’ll introduce the concepts of identification trust, authenticationtrust, reputation trust, session trust, and Trust Level upgrades anddowngrades. Additionally, we’ll discuss how to implement such a model as partof a Service-Oriented Architecture (SOA) by making use of the availableindustry standards.

Challenges

Organizations face a number of challenges with respect to theirAccess Control:

Scalability. The e-businessportfolio of organizations will strongly expand and new e-business servicesthat require a high level of protection against fraudulent activities will haveto be supported. This requires IAM functionality that is scalable from aquantity perspective and, even more importantly, from a security perspective.

Cost reduction. The implementationand management of adequate IAM functionality is a costly exercise.Organizations aim for sharing IAM functionality between their businesses.

Federation. Organizations willenter into more partnerships in which the partners may take responsibility forpart of the IAM services based on a well-established trust relationship betweenthe organization and these partners. On the other hand, identificationprocesses are expensive, and organizations that have implemented theseprocesses can benefit by providing services to other organizations.

Client-centricity. Organizationswant to be considered “easy to do business with.” Concepts likeclient-centricity are therefore important. Even organizations comprisingextremely loosely coupled businesses and their partners must offercross-business product portfolios to their consumers. Many cases require agroup portal strategy for this purpose. Such a strategy can succeed only whenit is supported by IAM services, which ensure that identity and authenticationinformation can be exchanged between businesses without compromising theirautonomy.

SOA compliance. Within an SOAarchitecture, the business processes are enabled via loosely coupled,coarse-grained, and reusable business services. The business services areexposed via technical interfaces based on industry open standards. Thereusability of the services can only be achieved when appropriate controls arein place for protecting and ensuring service availability. Access Controlinformation must be communicated between service consumers, service providers,and between all enterprise components that make up the services. Traditionally,Access Control functionality was part of and integrated within several ITinfrastructure components like operating systems, applications, and networkcomponents; the challenge now will be to implement this functionality as sharedIAM services that are integrated within the Enterprise Service Bus.

Trust, Trust, Trust...

Only effective communication of IAM information such asidentities, authentication assertions, or access policy decisions can addressall of the challenges mentioned so far. Communication of IAM informationrequires the establishment of trust between theparties that are involved.

As described by the International Telecommunications Union, anentity can be said to “trust” a second entity when it (the first entity) hasreason to assume that the second entity will behave exactly as the first entityexpects.

Trust relationships are sometimes obscured but in essenceexchange of information (not data) can only succeed based on some form ofdirect or indirect trust between the communicating parties. This applies inparticular to the IAM information that is used for the protection of theresources, the assets of the organization. Transactions in IT systems, whetherbusiness, IAM, or technical transactions, represent some value or risk for theorganization. Compromising a transaction may result in illegal access to aprotected resource, which may lead to financial, reputation, or other types oflosses.

In developing strategic IAM architectures, it became clear thatwe must formalize the trust concept in order to address the various challenges.In our model, the behavior as described in the definition is determined bypolicies that are established between the two entities. The level to which thereceiver is able to trust the information that is received is dependent upontwo things:

·        Thecorrectness of the way in which the policy was executed.

·        Thepolicy that was agreed upon to generate the information.

Our Trust Model captures these two items by means of so-calledTrust Levels. These Trust Levels are quantifiable and verifiable and,therefore, can be communicated between parties. The model requires anestablished governance framework.

Does Absolute Trust Exist?

This question should probably be answered by philosophers, but inthe reference frame of Access Control, the answer is no. However, the absenceof absolute trust does not bother us, because we don’t need it. In fact, we donot want it, because of the disadvantages that are associated with obtaininghigher levels of trust, such as additional costs and inconvenience for users.

IAM’s main objective is to provide Access Control to protectedresources. The level of Access Control must be commensurate with the level ofvalue/risk of the transactions executed against the protected resource. A levelof protection that is too stringent for the type of transaction may result inhigh costs or bad user experience. A level of protection that is too low willincrease the risks that are associated with the transactions. In other words, we need to be able to create, maintain, and communicate variouslevels of Trust in order to tune the level of Access Control to the value/riskof the IT transactions that are involved.

Trust Model

The IAM reference architecture includes a model that allows forsuch required commensuration of the level of Access Control to the value/riskof the IT transactions (see Figure 2). The core of this Trust Model consistsof:

·        Aclassification of the IT transactions into value/riskcategories (four to six categories are often sufficient).

·        Definitionof four IAM parameters and appropriate levels tocapture and communicate Trust:

      1. Identification Trust Level (ITL)

      2. Authentication Trust Level (ATL)

      3. Reputation Trust Level (RTL)

      4. Level of protection of the Authentication Assertion

·        Associations of the value/risk transaction categories withthe parameter levels for the various Subject Types and Roles.

·        Definitionof mechanisms to communicate the parameter levelsbetween the various infrastructure components that are involved in theexecution of the IT transactions; and definition of mechanisms to enforce therequired parameter levels by the resource in order to grant access.

Figure 2. Trust model

Let’s take a closer look at the four IAM parameters.

Parameter 1—Identification Trust Level.To explain the ITL parameter, we’ll first define some terminology. The termsare capitalized.

·        Subject. Subjects access protected Resources. A Subjectis a person, computer, device, service, or other entity that has, or will beprovided, access to Resources, or has accessed Resources in such a way thataudit records still have to be kept.

·        Subject roles. In accessing Resources, a Subject cantake on different Subject Roles. For example, a Subject of type “Person” canassume the Subject Role of “Personnel” but also the Subject Role of a “Client.”In other words, employees can act on behalf of the organization in doing theirdaily work or act on behalf of themselves as clients of the organizationprocuring products or services.

·        Digital identity. For a Subject to access a Resource,it must claim a Digital Identity (of type Security Principal). A DigitalIdentity is the representation of a Subject in the digital realm. A DigitalIdentity is a collection of related electronic data that represents theAssertions made by an Authority about the Subject. The Digital Identity isintended for use as a proxy of the Subject. There are various types of DigitalIdentities.

·        Identification. Identification is the process ofverifying (at a certain level of surety) the claimed Identity of a Subject andassigning a Digital Identity to the Subject. The Subject receives Credentials.Parties establish a contract (Identification Contract) during Identification.

An Identification Authority or Identification Agent performs theIdentification. The Identification Authority applies an Identification Policyin order to identify a Subject. The Identification Policy dictates the stepsthat the Authority needs to perform. A typical example of such steps is: TheAuthority physically meets the Subject, verifies his or her passport, and makesa copy (please note that there is also a trust relationship here with theAuthority that issued the passport). The Identification Policy also defines theway the Credentials are distributed to the Subject. This is a strongIdentification Policy that may be applicable to high-risk businesstransactions. For a low-risk business transaction, another IdentificationPolicy may be applicable that only prescribes that the Subject must provide avalid e-mail address and that the Credentials are sent to that e-mail address.Typical examples of Identification Authorities are a PKI Certificate Authority,an authorized human resources employee, front desk employee, or even automatedprocesses.

Identification processes are expensive and may require manualinteraction and involvement of third parties. They may also require involvementof the clients and tend to be experienced as unfriendly. So, define and—ifpossible, share—the most optimal process (do just enough) within or acrossorganizations.

The strength of the Identification is mainly related to thestrength of the verification steps (policy) performed by the IdentificationAuthority. This strength is reflected as so-called Identification Trust Level,and represents the level of assurance in the authenticity and integrity of aSubject’s claimed (legal) identity (the assurance that the Digital Identityrepresents the Subject).

The ITL serves multiple purposes. In addition to the role itplays in Access Control, it is required for identity associations. Organizationsoften have multiple Digital Identities for the same Subject. In many cases,this is an undesirable situation. The processes to associate these DigitalIdentities—initiated by the organization, but preferably driven by theSubject—will rely on the ITLs that are assigned to the various DigitalIdentities.

Parameter 2—Authentication Trust Level.Authentication verifies and confirms a Subject’s asserted Digital Identity witha specified or understood level of confidence. Credentials that are issued as aresult of Identification are used as proof that the Subject has the right toclaim the Digital Identity.

There are various strength levels for the Credentials, such assingle factor username/password and more stringent forms like multifactorusername/password combined with smartcards or biometrical traits. TheAuthentication strength is also dependent on the controls applied whenestablishing the session with the Subject and aspects like the channel, devicetype, location, and time also influence the strength of the Authentication.

The ATL represents the current session’s Authentication strength.The Authentication Authority (which was involved in the verification of theprovided Credentials) determines the ATL.

Parameter 3—Reputation Trust Level.Reputation Trust represents a party’s expectation that another party willbehave as assumed, based upon past experience. Reputation Trust isbidirectional and can be split into Consumer Reputation Trust and ProviderReputation Trust.

The type of transactions that are performed, authenticationhistory, and so on, can influence the Consumer Reputation Trust. The ConsumerReputation Trust is a dynamic parameter and can vary within a session. ConsumerReputation Trust will become an important parameter, and provisions in the IAMarchitecture capture, maintain, and communicate the RTLs; however, the exactdefinition is dependent on the specific situation and still subject to furtherinvestigation.

A client who is performing an e-business transaction will also implicitlyestablish a Provider Reputation Trust regarding the e-business provider. Ane-business provider must strive towards a situation in which the ProviderReputation Trust, as perceived by the client, is commensurate with thevalue/risk level of the transaction—for example, by the use of ExtendedValidation SSL Certificates and personalized welcome messages for higher-risktransactions.

In this article, we focus on the consumer side of the ReputationTrust. The three parameters that are discussed so far (ITL, ATL, and RTL) needto be communicated between the service consumer and provider. Parameter 4guarantees their integrity and authenticity at an appropriate level.

Parameter 4—Protection of theAuthentication Assertion. A protected Resource or Service Provider needsto receive an Authentication Assertion (security token), which allows it toenforce Access Control policies to determine if and to what extend it willgrant access to its services. The enforcement of the Access Control policiesmay be delegated to a “centralized” Policy Enforcement Point (PEP) supported byPolicy Decision Points (PDP).

In the model, the Authentication Assertion contains Identityinformation combined with the ITL, ATL, and RTL and possibly other attributessuch as privilege attribute certificates, to enable subsequent authorizations.The Identity information that is contained within the Authentication Assertionmay reference various types of Digital Identities:

·        Persistent identity. The Digital Identity originally claimedby the Subject at Authentication (also referred to as proclaimed identity).

·        Implied identity. The Digital Identity used byintermediate services to access “lower-level” services in a trusted subsystemmodel.

·        Initiating identity. A Digital Identity representingthe person initiating the transaction. The need for such an identity isapparent in the following scenario: A client instructs a service desk employeeto perform a transaction against his/her account. The persistent identityrepresents the service desk employee. However, the identity of the client alsoneeds to be kept and communicated. This identity is called the initiating identity.

·        Domain identity. A Digital Identity associated with theSubject within a dedicated application or business domain.

The Authentication Assertion requires protection because itcontains information that must not be compromised while stored or in transport.The authenticity and integrity of the Authentication Assertion is crucial,while the confidentiality of the Authentication Assertion is in most cases lessimportant, regardless the fact that integrity may be enhanced by applyingconfidentiality (security by obscurity).

Protection of the Authentication Assertion is a considerable costfactor due to the required processing needed for encrypt and decrypttechnologies. Therefore, the protection should be tuned to the value/risklevels of the transactions. In some cases, an SSL/TLS or IPsec transport layersecurity will suffice, while other situations require message-layer security byapplying WS-Security with various encryption levels.

The IAM reference architecture defines three levels for theprotection strength of the Authentication Assertions. The service providerneeds to enforce, by means of its policies, that the required level has beenapplied.

Associating Value/Risk Transaction Levels with theParameter Levels

After they have been defined, it is possible to associate thevarious transaction value/risk levels and parameter levels. This needs to bedone for each Subject Type and Subject Role. For example, the mapping for aSubject of Type "Person" in Role "Personnel" will differfrom a Subject of Type "Person" in Subject Role "Client."Their identification policies, the way they authenticate, and the transactiontypes, may all differ. It is also necessary and possible to includetransactions in the model that are not directly related to the core business ofthe organization. This concerns transactions such as IT administratortransactions and IAM transactions for Subjects in the Role"Personnel."

Figure 3 shows how you can associate the transactions to the ITL,ATL, RTL and Authentication Assertion Protection Levels for the Subject Role"Client."

Figure 3. Associating value/risk transaction levels with theparameter levels

In order to execute this specific transaction in the value/riskcategory "Medium," the following minimum parameters must be met:

·        ITLC30 stands for: an Identification Policy that includes documented proof, copyof passport, Credential distribution by out-of-band mechanism.

·        ATL4 stands for: user name and strong password, combined with one-time PIN via cellphone.

·        RTL50 stands for: no incidents, no history yet.

·        AuthenticationAssertion Protection level B stands for: transport layer security, AES 256 bitsencryption.

Before we discuss how the Trust Model should be implemented, wemust introduce the concept of Trust Level upgrades and downgrades.

Trust-Level Upgrades and Downgrades

A protected Resource will enforce an Access Control Policy, whichdictates that certain minimum levels of ITL, ATL, RTL, and AuthenticationAssertion protection must be met. If the levels are not appropriate, it rejectsthe service call and requires higher Trust Levels. This triggers a processrequiring additional Credentials such as a PIN. This is called an ATL upgrade.Some IAM product suites support ATL upgrades.

ITL upgrades and downgrades are also possible. A typical exampleof an ITL upgrade is when an existing e-business client enrolls for higher risktransactions and is required to come to the office and provide a copy ofhis/her passport. The security principal that he/she uses will stay the samebut it gets a higher ITL assigned. An ITL downgrade may occur when anIdentification renewal process was not executed in time, or when some of theverifications executed during the initial Identification are no longersufficient.

An RTL upgrade may happen when there is regular use and noincidents are reported over a certain time period. A (temporary) RTL downgrademay be the result of the fact that the user has lost part of his/herCredentials.

Implementation

The ITL, ATL, and RTL are combined into what is referred to asthe Session Trust object. Listing 1 shows thestructure:

Listing 1. Structure of the Session Trust object

Session Trust is the level of surety that the Digital Identitywanting to transact actually originates from the Subject, whose identityinformation is linked to the Digital Identity, and that this Subject willbehave in the agreed-upon manner.

The Session Trust object must be communicated as part of servicerequests and forms part of the Security Token embedded within these requests.There are various alternatives, but consider the implementation in a Web Servicesenvironment in which the Authentication Assertion is formatted as an SAMLAuthentication Assertion (SAML element <AuthnStatement>).The <AuthnStatement> elementprovides a means to capture the Session Trust object via its definition of theAuthentication Context (<AuthnContext>)element.

According to the SAML standard: “A particularauthentication context declaration defined in this specification will capturecharacteristics of the processes, procedures, and mechanisms by which theauthentication authority verified the subject before issuing an identity,protects the secrets on which subsequent authentications are based, and themechanisms used for this authentication.”

The <AuthnContext>element is extensible and provides the rudimentary structure to capture SessionTrust. The architecture prescribes an extension of this structure to cater tothe full Session Trust object.

Suppose parameter 4 indicates that the Authentication Assertionmust be protected by message-layer protection. In that case, use theWS-Security standard and place the SAML Authentication Assertion in a <wsse:Security> element of theSOAP header. To meet the required authenticity and integrity requirements, theissuer or attesting entity will sign the Authentication Assertion and the encryptionalgorithm and key length must meet the complexity as defined for parameter 4.

The Service Provider needs to implement (WS-Policy) servicepolicies to enforce compliance of the four parameter values to the ITtransaction value/risk levels of the services that it provides. It willvalidate the ITL, ATL, and RTL and will only accept service requests that meetthe required level of protection of the contained Authentication Assertion. Ifthese levels are not met, it will inform the service consumer, which mayinitiate a Trust Level upgrade procedure to meet the required levels. TheService Provider may delegate some of this verification to a Security TokenService (STS), which may also cater to Security Token transformations based onits established trust relationships with Authentication Authorities.

The Session Trust object contains consolidated information aboutthe executed Identification and Authentication process and changes thatoccurred in the Reputation. The information contained in the object iscondensed in such a way to enable communication in various technology sets andprotocols. Web Access environments may require implementation of the SessionTrust object within the HTTP header, which has its length limitations.

More elaborated Access Control mechanisms need additionalinformation on top of the Session Trust object. The IAM services maintain aso-called Trace object, which reflects all thedetailed information about the performed Identification and Authenticationprocess steps and Reputation changes.

Listing 2 provides a possible structure for the Trace object:

Listing 2. Structure of the Trace object

The Identity Services will maintain the first and last part,while the Authentication Authorities will cater to the second part. The Traceobject also plays an important role in auditing the IAM processes.

Note that the object caters to multiple Identification andAuthentication steps and Reputation changes to register Trust Level upgradesand downgrades. The Trace object is associated with the unique identifier thatis assigned to the Digital Identity, as maintained by the Identity Services.

Let’s consider a typical scenario for Authentication toillustrate the implementation of the Trust Model, as shown in Figure 4:

Figure 4. Authentication

(1) The Subject provides its Credentials to the AuthenticationAuthority. (2) The Authentication Authority fetches the unique ID (a GUID inthis example) and the ITL and RTL from the Identity Service. If needed, it mayinterrogate the Identity Service for more detailed information contained in theTrace object. The Authentication Authority determines the ATL and updates theTrace object to reflect the Authentication steps it has performed. (3)Subsequently, it propagates the service request to the Service Provider andembeds the Identity information and Session Trust object in the service call.(4) In this example, the Service Provider implements its own unique identifier(Domain Unique Identifier) for the identity and queries the IdentityInformation Service about the association of the unique identifier to theDomain Unique Identifier. The Service Provider can also fetch the Trace objectfrom the Identity Information Service to get more detailed information ifrequired.

Conclusion

We started this by addressing the business and IT challenges. Theability to communicate Identity and Access Management information betweenparties is the key. Facilitating such communication requires quantifiable andverifiable Trust Levels. This applies to parties such as businesses withinorganizations, an organization with its partners, and also services in an SOAarchitecture.

Additionally, in order to meet the challenges, enable AccessControl Policy enforcement at the to-be protected Resource at a level that isadequate for the situation at hand, tuned to the value/risk level of thetransaction.

As developed, the architecture—of which we discussed elementssuch as Session Trust object, Trace object, and the mapping of the variousTrust Levels to the value/risk levels of the business transactions—is capableof addressing these challenges from a technical perspective. However, it allboils down to the willingness of the parties that are involved to cooperate,establish formal agreements for this cooperation, and adhere to thoseagreements. But isn’t that the main challenge in the whole Identity and AccessManagement domain?

Resources

International Telecommunication Union ITU-T Recommendation X.509(03/2000)

Web Services Security: SOAP Message Security 1.1, OASIS StandardSpecification, 1 February 2006

Web Services Security: SAML Token Profile 1, OASIS Standard, 1February 2006.

Assertions and Protocols for the OASIS Security Assertion MarkupLanguage (SAML) V2.0, OASIS Standard, 15 March 2005

Authentication Context for the OASIS Security Assertion Markup Language(SAML) V2.0, OASIS Standard, 15 March 2005

About the authors

Gerrit J. van der Geest is an IT architect and programmanager who has over 25 years of experience in IT. Gerrit holds a master’sdegree in applied physics from the Eindhoven University of Technology in theNetherlands. He is cofounder of consultancy companies in the Netherlands and inSouth Africa. Prior to that, he held program management positions at DigitalEquipment Corporation and Philips, where he was responsible for many internationalsystem-integration programs.

Gerrit specializes in IAM, SOA, and infrastructure architectureand has been responsible for the development of IT strategies, domain, andsolution architectures for large insurance and manufacturing organizations.Gerrit welcomes feedback at gerrit@navit.co.za.

Carmen de Ruijter Korver is a program manager withexperience in IT infrastructure programs and architecture assignments. Sheworked for Compaq in the Netherlands, where she was responsible for the setupof a program management office and worked on many international ITinfrastructure programs. Thereafter, she cofounded Navit (Pty) Ltd. in SouthAfrica, where she specialized in the area of IAM, with a focus on IAM migrationstrategies. Carmen is a PMI and PRINCE2 certified program manager.

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.