IAM System Architecture

Architectures of comprehensive identity and access

management

Ivan Milenković, Uroš Šošević, Dejan Simić

University of Belgrade Belgrade, Republic of Serbia

[email protected], [email protected], [email protected]

Abstract— When designing an identity and access management (IAM) system, system architect needs to make several decisions. One of the most important decisions is the choice of adequate system architecture. As the need for identity and access management systems is on the rise, numerous different IAM system architectures have been proposed. Some of them were described roughly, other in more details, but certainly there have been some scientific contributions in this area. However, in available literature we have not found any paper that gives a detailed overview, or comparison of different IAM architectures. Therefore, in our paper, we give an overview of different architectures. Special attention was given to identification, authentication and authorization processes.

Keywords-identity management; system architecture; authentication; identification; authorization; access management

I. INTRODUCTION

In the last decade, the area of identity and access management has developed significantly. With the rise of the network-based, automated services, traditional ways of establishing trust relationships between negotiating parties are no more applicable, as customers purchase or use services delivered to them electronically on their computer. Windley [1] points out that the usual trust marks that customers have relied on in the past are either missing or easily forged. Therefore, because of increased risk of attacks such as identity theft and identity disclosure, properly implemented systems for identity and access management are of the utter importance.

Beside business, identity and access management systems have application in many different areas, such as e-government, social and educational networks or border control. Al Khouri [2] states that the last few years have witnessed the evolution of the digital identities or so called e-Identities by various Governments across the world. According to United Nations E-Government Survey [3], South Korea holds the first place in implementing digital IDs and national ID based commercial transactions. Moreover, smart cards and biometrics are frequently used for border control and national IDs [4]. For example, visitors to US have to pass through US-VISIT programme, have their fingerprints scanned, and photos taken.

Before further elaboration on the topic of identity and access management it is necessary to pay some attention to the concept of identity. When we refer to identity, it is necessary to define in which context it is used. For example, identity from a

legal point of view may differ much from identity as a psychological or philosophical concept. Even if we narrow our area of interest to the field of information technologies, a single entity may have multiple identities. Therefore, as stated in [5], identity should be viewed as a concept of uniquely identifying an entity (person, organization, computer, etc.) within a given context.

Each identity consists of different attributes and relationships with other entities. Attributes may be transient, such as the number of bank account, or permanent such as the date of birth. Some of them are unique across certain domain, for example a passport id number. When an attribute is used for identification or authentication, it is called an identity credential. Types of credentials may vary from usernames and passwords to digital certificates, tokens or usage of biometric modalities.

Identity and access management (IAM) process has several fundamental parts - user identification, authentication and authorization. These three activities are tightly bonded, as they form a chain of dependencies. Authorization depends on authentication, while authentication relies on result of identification. Also, activities such as auditing and user provisioning are important parts of an identity and access management system. Using IAM has one main advantage, which is a resulting synergy of activities mentioned above. It reduces operational costs and increases security of a system. In order to get best results from such synergy, it is necessary to use IAM system architecture which most adequately suits given system requirements. Because of that, different IAM system architectures will be thoroughly analyzed in the following sections of this paper.

In the next section main entities of IAM architectures are introduced and the paper problem statement is given. Current state of brand-name and open source IAM systems is then discussed. Next, identification, authentication and authorization processes are described and conceptual entity data model is presented. In the last paper section, several generic IAM system architectures are presented.

II. PROBLEM STATEMENT

Before we state the problem, it is substantial to define terms that represent basic concepts of IAM system architecture. For all IAM architectures, following entities can be recognized [6]:

 System user

 Identity provider

 Service provider

System user is a consumer of services provided by the system. User must own at least one identity in order to use available services within a context defined by owned identity. To confirm the claimed identity, system user communicates with identity provider. Identity provider is responsible for accepting or denying users identity, but it is also strongly tied with service provider. This way identity provider confirms or propagates identity information to service provider. Depending on the information received from identity provider, service provider allows or rejects usage of requested services. For more detailed description of entity roles it is necessary to define IAM system architecture.

Figure 1 – Three layers of identity and access management systems In development of identity and access management systems, a three layer design approach could be adopted [7]. This approach recommends presence of technical layer, logical layer and user layer, respectively (starting from lowest position). These layers are distinctly separated, but each layer is based on concepts of higher positioned layer. On user layer, IAM system requirements are specified, and expected functionalities are described. Based on specifications defined on user layer, a logical architecture is created. It reflects system components, their roles and relationships. Technical layer stands on the lowest level of IAM system design. On this layer, hardware components that implement logical layer contents are presented. It is important to mention that these layers are limited by some legal, social and policy constraints. As these constraints are outside the scope of this paper, they will not be discussed. IAM system architectures defined in this paper are part of logical layer, as they present a blueprint for implementation on technical layer. Three layers of identity and management systems are presented on Figure 1.

While surveying literature available on the topic of identity and access management, we have not discovered an article, paper or book chapter which gives a detailed theoretical overview of IAM system architectures. Some papers have partially covered this research area, but none of them had a broad area overview as an important objective. Other authors, like [8], have given a broad overview of different identity management models and paradigms, but they have not analyzed in detail various IAM system architectures. Therefore, the goal of this paper is to present an overview of different IAM system architectures. In each architecture description roles of service provider, identity provider and system user will be described in detail. Special attention will be given to identification, authentication and authorization processes, as it is important to define who is responsible for these activities.

III. CURRENT STATE OF IDENTITY MANAGEMENT SYSTEMS Since identity management systems play an important role in every organization, there is a need to constantly develop and improve these systems. There are many different vendors of proprietary identity management systems, but also a fair number of open source initiatives is present. Some of the most popular vendors are:

 Microsoft  Hewlett Packard  IBM  CA technologies  Courion  Novell

Microsoft’s Active Directory Services (ADS) component includes an integrated identity management system. As of Windows Server 2003 R2, Active Directory Federation Service (AD FS) is an integral part of ADS. It is used to create trusts between organizations. This is done by authenticating users through Active Directory, which represents an identity provider. Also, AD FS issues and validates tokens which are used in the authentication process.

Beside ADS, Microsoft has released Microsoft Identity Integration Server (MIIS). It has undergone several name changes and in 2010. Forefront Identity Manager (FIM) was presented. FIM was developed to integrate with Active Directory and Microsoft Exchange, thus using already familiar components.

Hewlett Packard offers identity management as a service. Their IAM service includes Automated user provisioning service, Credential management services and Directory management and Federation services.

As a part of their Tivoli suite, IBM provides identity management system based on policies and roles [9]. Tivoli Identity Manager is a comprehensive IAM system. It offers various features such as: role hierarchy, web self-service, group management, provisioning engine, synchronization of user data from different repositories etc... Also, it is possible to integrate

Tivoli IM with the most popular business applications (ERP systems, service desks, etc.).

CA technologies has developed an identity management system called CA Identity Manager. This system provides role and policy analysis and control, as well as automated provisioning. It is designed to function with CA Role and Compliance Manager and other CA products. Also, it uses its own CA directory, but has a support for other databases (Active Directory, SAP, etc.).

As regards the open source identity management systems, there are several freely available at the moment. Some of them are:

 OpenIAM

 Central Authentication Service project (CAS)

 Shibboleth

OpenIAM is an open source identity and access management solution. It contains two products: Identity Manager and Access Manager. In addition to self-service, password management and password policies, Identity Manager provides delegated administration. Provisioning, auditing and reporting are also supported by OpenIAM Identity Manager. It is seamlessly integrated with OpenIAM Access Manager and also can be applied within Active Directory, Exchange and even cloud based Google Apps.

CAS is an authentication system created by Yale University. In 2004, it became a Jasig project. Simple single sign-on is the main feature of this system. It enables authenticating users by using password (LDAP, databases or RADIUS), but it is also able to authenticate users without using password (by using X.509 certificates or SPNEGO/NTLM).

Shibboleth is another web-based single sign-on (SSO) authentication system. Besides providing access to services inside organization, Shibboleth provides SSO support to services that are outside of user’s organization while still protecting their privacy.

IV. IDENTIFICATION, AUTHENTICATION AND AUTHORIZATION

In common literature, the user identification process is often neglected. Some authors, like [10] refer to identification as a part of user authentication process. Such generalization can sometimes be misleading. For example, let us consider a common example, identification and authorization via user names and passwords. In that situation, we can clearly recognize two different, interconnected steps. In the first step, a user name is utilized for identification, while in the second we use the provided password to assert identity claim. Because of that, it is necessary to separate identification and authentication. The process of claiming user identity should be considered as identification, while the process of verifying this identity should be nominated as authentication.

Figure 2 – 2009 European Identity and access management survey; authentication methods usage frequency [11]

There are many different methods for user authentication. Most of the methods can be classified in one of the following three categories - password based methods, tokens, and biometrics. Figure 2 gives [11] an overview of usage frequency for several authentication methods. Password-based methods are the most common, and they use something the user knows as the authentication method. An alternative approach for system user to authenticate would be the usage of token, something he/she possesses. Both of these methods have several disadvantages, as passwords can be forgotten and tokens stolen. Some of the disadvantages can be solved with the usage of biometrics. Biometrics use system user’s physiological or behavioral characteristic for authentication, something that he/she is. In Table 1 a comparison of different authentication methods is given [12].

Table 1 - COMPARISON OF VARIOUS AUTHENTICATION METHODS BASED ON THE PERCEPTION OF THE AUTHORS

Authentic. method

Cost Acceptability Non repudiation

Level of security

Password Low High No Low

Digital certificate

Medi

um Medium Yes High

Biometrics High Low Yes High

Authorization is the process of asserting user rights to access certain resources, such as data, computer devices, or application functionalities. Within an application, different users may have various types of permissions. For example, a document management system will have permissions “create”, “read”, “edit”, “delete”. Permissions should be given using “the principle of least privilege”, system user should be given only those permissions they need to successfully do their work. [13]. User provisioning is closely related to the authorization process. To illustrate this, let us think of corporate information system. When we assign an employee to a different position, authorization rights should also be updated to match new work tasks.

Beside identification, authentication and authorization processes, it is important to define key data entities that are present in identity and access management (Figure 3). These data entities are described with three data elements:

 Identifiers

 Credentials

 Identity attributes

Figure 3 – Identification and access management conceptual entity data model Data that are unique to an entity represent identifiers. Identifiers can be personal identity number, driver’s license number, organization identification number, etc. When using identifiers, it is important to attach domain information as uniqueness of identifier is valid only inside the used domain. Credentials are data used by an entity in identification and authentication processes. They appear in form of passwords, digital certificates, biometric data, etc. Identity attributes are other entity data that are present, but not necessarily used in the identification, authentication and authorization processes. Such data could be name, organization founding date, address, etc. One thing that needs to be emphasized here is that identifiers and credentials should not be strictly separated. For example, even though personal identity number is classified as an identifier, it could also be used as a credential. And vice versa, although biometric data (for instance, a fingerprint) is used as a credential, it also represents an identifier.

V. GENERIC ARCHITECTURES FOR IDENTITY AND ACCESS MANAGEMENT

In our review of different real-world implementations of identity and access management systems, we have noticed that they follow several patterns. That gave us an idea to mark out certain common parts and use them to develop some generic IAM architectures. In order to describe each of the architectures in a clear and understandable way, a visual presentation approach was used. Main IAM system building blocks - entities and their relationships are represented using block diagrams. Moreover, order of identification, authentication and authorization steps is shown, thus enabling quick and easy overview of the IAM process workflow.

Figure 4 – Centralized IAM architecture

A traditional approach to identity and access management is the centralized IAM system architecture. In this case, we have only one, centralized identity provider and all system services are provided by a single service provider. This architecture is shown on Figure 4, and process steps are numbered. In Step 1 system user identifies himself to identity provider. After successful identification of system user, the system needs to authenticate the user. Identity provider is responsible for both identification, and authentication. Additionally, in current scenario, identity provider is also responsible for authorization activity. After completion of authentication, user receives a token from identity provider (Step 2), which is passed to service provider in Step 3. Token is used by service provider to verify user credentials and claims. This is done in Steps 4 and 5, where identity provider and service provider communicate in order to validate information carried by the token. After successful validation, system user is eligible to use desired services (Step 6). It is important to notice that all IAM architectures described in this paper follow previously described steps.

Figure 5 – Identity provider: Identification, authentication and authorization modules

As authentication and authorization are two different activities, it is possible to distribute responsibilities for them to Entity

separate entities (Figure 5). In an alternative scenario, instead of identity provider, service provider is in charge of authorization(Figure 6). Also, it is possible to make both identity provider and service provider responsible for the authorization process. Coarse grained access control on identity provider could be used to determine if the user can access desired service at all, while fine grained authorization would be done on service provider.

System User Identification module Authentication module Authorization module Service 1 Identity provider Service provider

Figure 6 – Service provider responsible for authorization

In another approach, there are several identity and service providers, and instances of the same entity type are mutually independent. Existence of multiple entity instances qualifies this architecture as heterogeneous. As there are several service provider entities, each service provider forms a chain of trust with at least one identity provider. It is possible that certain identity provider is in charge of more than one service provider. When system user wants to utilize service/s offered by certain service provider, one needs to identify and authenticate with one of identity providers that are responsible for chosen service provider. As a result of various combinations when interconnecting all present entities, a mashed structure is formed. Thus, IAM system based on this architecture is a mashed heterogeneous system and its layout is shown on Figure 7.

Figure 7 – Heterogeneous mash IAM architecture

Mashed IAM architectures often appear when it is not possible to apply other alternatives because of organizational constraints. A system user can use services from different providers, and each service provider may rely on different identity provider. Also, in large enterprises, it is not an unusual situation in which an organizational unit refuses to integrate its system with other departments. Other reasons would be the existence of legacy systems, or former attempts to establish an IAM system.

Described mashed architecture has some disadvantages. Using various identity providers can be discomforting for system users, as they have to identify and authenticate several times. If password-based authentication methods are used, system users have to memorize password for each identity provider, and as the number of identity providers increases, this process becomes more intimidating. System usability also suffers if various identity providers rely on different authentication methods. Beside system usability, user provisioning is also a potential problem. Because there are several instances of identity and service providers, it can be hard to keep user data consistent and up to date. As a result, access management and auditing are a bit of a challenge for this architecture. We will discuss several IAM architectures that could try to solve most of, or even all noticed issues.

Next IAM architecture exploits the fact that multiple identity providers could share information they have. By sharing the information and agreeing to work together identity providers form a “federation”, thus allowing system users to identify with any identity provider belonging to the federation. Because of that, this architecture is called Federated IAM architecture [14]. Main advantage of federated IAM architectures is that it enables system to work even if service provider and identification provider are not in the same organization. The Federated IAM architecture is shown on Figure 8. System User Service Provider 1 Identity Provider 4 Identity Provider 2 Identity Provider 3 Identity Provider 1 Service Provider 2

Following set of IAM architectures is based on single sign-on (SSO) paradigm. SSO means more csign-onvenience to system user by enabling him to give his credentials only once, without need to repeat the identification and authentication process when accessing other services. In this way, ‘need for multiple identification and authentication’ issue is solved. In first SSO architecture we have presented on Figure 9, there is a centralized identity provider which represents a single sign-on point. Beneath it, on the lower level, there are numerous service specific identity providers. System user identifies and authenticates with centralized identity provider, while authorization process is delegated to service specific identity provider. It is important to highlight that centralized identity provider does not care about authorization, nor its data. After initial sign on, user only needs to authorize with service specific identity provider in order to get access to desired service.

Figure 9 –Centralized single sign-on IAM architecture

Biggest imperfection of centralized SSO architecture is that system relies on centralized identity provider. In case of a failure, whole system is unusable, as there is no way for a user to identify. Another problem arises when number of service specific identity providers significantly increases. It is unpractical and difficult to achieve proper functioning of such system from not only technical but also organizational point of view. Therefore, instead of using a centralized identity provider, an alternative approach would be integration of different administrative domains into a single virtual domain. The following federated single sign-on IAM architecture is more flexible and easier to implement than the centralized model.

In federated SSO architecture, as it is shown on Figure 10, identity providers establish mutual trust agreements. As result of these agreements, user identities from different administrative domains are recognized across all domains. When user authenticates to a single service provider, it has the same effect as if he has authenticated with all other service providers from that federation. Some of technology standards for identity federation are the Security Assertion Markup Language, OpenID and OAuth protocols.

System User Service Provider 1 Identity Provider 4 Identity Provider 2 Identity Provider 3 Identity Provider 1 SSO point Service Provider 2

Figure 10 – Federated single sign-on IAM architecture VI. CONCLUSIONS

Identity and access management appears as a mandatory and critical system in almost every organization, but also is an expensive investment. Therefore, it is important to select suitable IAM system architecture, in order to minimize the cost of establishing such system. In this paper, we tried to present advantages and disadvantages of recognized generic IAM system architectures. These architectures are logical view of an IAM system, as they are represented by identity provider, service provider and system user components and their relationships.

There is no universal IAM architecture that best suits all organizations. But, depending on requirements that exist in certain organization, one of generic IAM architectures could be used. Proposed centralized IAM architectures would be adequate for use in smaller organizations, while in more complex organizations, both centralized and non-centralized (Federated and Heterogeneous mash) would be suitable.

Even though five presented generic architectures cover significant amount of IAM systems, this number is not final. Further research should focus on modification and more detailed description of these architectures. Also, this paper barely scratched the surface in terms of constraints that are present in this research area. Therefore, it is important to thoroughly explore and discuss those issues in future work.

ACKNOWLEDGMENT

This work is a part of the project Multimodal biometry in identity management, funded by Ministry of Education and Science of Serbia, contract number TR-32013.

REFERENCES

[1] P. Windley, Digital Identity, Sebastopol, USA: O'Reilly, 2005

[2] A.M. Al-Khouri, “PKI in Government Digital Identity Management Systems”, European Journal of ePractice n° 15, 2012

[3] United Nations - Division for Public Administration and Development Management, “E-Government Survey”, 2012, Retrieved from http://www2.unpan.org/egovkb/global_reports/12report.htm

[4] M. Bogicevic, I. Milenkovic, D. Simic, “Identity Management – A Survey”, XIII International Symposium Symorg, Serbia, Zlatibor, 2012, pp.900-907

[5] S. Slone and The Open Group Identity Management Work Area, Identity Management White Paper, 2004, Retrieved from www.opengroup.org [6] R. Dhamija, L. Dusseault, "The Seven Flaws of Identity Management:

Usability and Security Challenges," IEEE Security and Privacy, vol. 6, March/April, 2008 , pp. 24-29

[7] K.Stefanova, D. Kabakchieva, R. Nikolov, “Design Principles of Identity Management Architecture Development for Cross-Border eGovernment Service”, 10th _{European Conference on eGoverment, June}

2010, pp. 367-375

[8] Y. Cao, “A survey of Identity Management technology”, IEEE Conference on Information Theory and Information Security (ICITIS, December 2010), pp. 287-293

[9] A. Buecker, D. Bhatt, D. Craun, J. Ramanathan, N. Readshaw, G. Sampathkumar, “Integrated Identity and Access Management Architectural Patterns”, 2008, Retrieved from http://www.redbooks.ibm.com/redpapers/pdfs/redp4423.pdf

[10] G. Prasad, U. Rajbhandari, “Identity Management on a Shoestring”, 2011, Retrieved from http://www.infoq.com/minibooks/Identity-Management-Shoestring

[11] J. Hermans and P. Valkenburg, “European Identity and Access Management Survey”, KPMG and Everett, 2009, Retrieved from http://www.everett.it

[12] L. O’Gorman, “Comparing Passwords, Tokens, and Biometrics for User Authentication”, Proceedings of the IEE, vol 91, issue 12, December 2003, pp 2021-2040

[13] J. Saltzer, M. Schroeder, “The Protection of Information in Computer Systems”, Proceedings of the IEEE, vol. 63, issue 9, September 1975, pp. 1278 – 1308

[14] S. Shim, G. Bhalla, V. Pendyala, "Federated Identity Management," IEEE Computer, vol. 38, 2005 ,pp. 120-122