As discussed in the first part of this blog series, the many benefits of digitalization involve managing the lifecycle of the customers identity. Providing self-service for access and changes set the requirements for these systems and for the services the system should provide. In this second part of the Datalounges CIAM blog -series we look into the components that make up these identity management solutions for customers.
This part introduces and explains the generic components of CIAM systems and the purpose they have. Such CIAM systems are a necessary part of any software-as-a-service solution and it is valuable to understand how the CIAM -component can benefit organizations providing such services.
Components of CIAM system
A CIAM system can be roughly divided into components based on the functions it provides. In Figure 4, the most important components are presented to get a better view of the system as a whole. Next chapters intend to deepen the technical understanding of the components from identity federation, federation protocols, user directories, customer portal and about their purposes for the system.
Figure 4: Components of a generic CIAM-system
Identity Federation
Identity Federation is the process of delegating an individual’s or entity’s authentication responsibility to a trusted external party. This allows the use of identity information outside the organization that manages it. The federated identity model can be broken into two main components Identity Provider (IdP) and Service Provider (SP). Both parties have their own set of responsibilities and establishing trust between both is required to enable a federated identity solution [15].
Identity provider´s task is to host identity information and authenticate users. In web applications, after the user presses the login button on service providers page, a redirect is made to the identity provider’s page, where login information is given. Then authentication is done and upon success user information and attributes are sent to be used by the SP.
SP is the party that offers services to others. These services can vary from applications to infrastructure or data services. In the federated identity model, the SP has delegated the management and authentication of users to the Identity provider and doesn’t have to be involved in it. However, now the service provider needs to trust the service provider and its information since that is used for authorization to services.
In the core of federated identity is the trust relationship between the parties. Identity provider must trust service provider since it sends it their user information and attributes. This is possible on the assumption that the service provider doesn’t misuse the information. In the service providers end, they rely on the IdP that their information is up to date and secure enough to authorize access to their services. The process of registration and strength of identity provider’s authentication is something a SP should take into account. SP could require their users to be real, and then the registration process in the identity providers end should reflect that. Of course in some cases SP could have looser requirements and would be fine with their users being self registered with ambiguous user information.
Main advantages and disadvantages of identity federation according to Derrick Rountree are following [15]:
Advantages
- Security of User Credentials
- Seamless User Experience
- Application only Make Authorization Decisions
- Reduce Account Management
- Reduce Number of Usernames and Passwords
- Ease Merger and Acquisition Activity
- Highly Extensible
Disadvantages
- One Key to the Kingdom
- Requires Specialized Infrastructure
- Need to Conform to Same Standards
Many of the advantages have already been talked about before. The ease of merger and acquisition strategy refers to cooperation between multiple organizations being easier since there would be no need to merge the separate IdM systems, but using identity federation organizations can use their own identity stores and federate access to another organization applications once trust relationships are established. On the disadvantage side, one key to the kingdom refers to the organization’s whole suite of applications being accessible with a single account, and in case that account is compromised, so are all the applications. This, however, is often disregarded since the positives of Single Sign-On and single identity are seen to outweigh the potential risks [15].
Identity federation is extremely relevant in the case of the CIAM system. As the CIAM system manages authentication, it works as an identity provider for the applications that are connected to the system. Not only does the basic use case utilize federation, but also the CIAM system could be configured to use federated user stores outside the system [24].
Single Sign-On
Single Sign-On (SSO) is one of the most important features provided by a CIAM system. With SSO users can access multiple services with a single user account. Although similar, SSO is different from the one identity and one password principle where services are accessible with the same account, but each requires the user to enter their login information separately [4]. When logged in with SSO, multiple services become available without re authentication for a set period of time. There are several ways of implementing SSO.
Pseudo SSO is a mechanism where a user is not actually logged in to all of the available services, but rather credentials are given to services automatically without user interaction. This can be done by saving credentials to cache either locally or by the SSO service, from there, credentials can be supplied forward to the services for authentication. This way, the end services authentication mechanisms don’t need to be altered [4].
In true SSO, the login event happens once and then is valid without reauthentication. This can be achieved by SSO service authenticating users once and returning a ticket that can be then used to access end services. A drawback of true SSO is that end services need to be configured to trust and accept SSO service’s tickets as a proof of user’s identity [4]. This requires additional work to the authentication infrastructure when compared to the pseudo SSO.
Federation protocols
There are multiple technologies for identity federation in Web environment, namely SAML (Security Assertion Markup Language), OAuth and OpenID. They all enable functionalities discussed before, but with different technologies. Next, I am going to present the protocols and their currently used implementations.
SAML
SAML is an OASIS (Organization for the Advancement of Structured Information Standards) standard, first ratified in 2003. It’s an XML-based language designed to allow authentication and authorization from a SSO perspective [25]. Its current version SAML 2.0 has been around since 2005 and is still actively used in several commercial and open source SSO solutions.
Figure 5: SP-Initiated SSO with Redirect and POST Bindings, Adapted from: [26]
- User is not logged in and tries to access a resource on the service provider’s site. SP saves the resource URL in local state information so that it can be used across the SSO exchange.
- SP sends a HTTP redirect to the browser with Identity Providers SSO service as a destination. The URL has SAML Authentication Request encoded as a query variable.
- The SSO service challenges the user to provide their login credentials if the user isn’t already logged in.
- User gives valid credentials.
- Security context for the user is created by the identity provider and a SAML assertion is built based on it. The assertion is placed in the SAML response that is placed within an HTML form and sent back to the browser.
- The SAML response is sent with POST to the SPs assertion consumer service that verifies the response.
- SP establishes if the user is authorized to access the resource and upon approval returns the resource to the browser.
OAuth 2.0
OAuth 2.0 is an open authorization protocol for delegating access on the internet. The protocol defines a way for the user to permit the application to do authorized tasks on the user’s behalf [27]. Access to services is granted by the authorization server that issues a token to the user after successful authentication. The authentication is not part of OAuth 2.0 protocol so it’s up to the identity provider to implement. With the access token, the application can perform authorized tasks permitted by the resource owner. Companies, such as Google, Amazon, Microsoft, Apple and Twitter, use OAuth 2.0 to share information about their users with third party applications.
OAuth 2.0 defines four roles for its authorization flow. The roles are Resource owner, Resource server, Client, and Authorization server [28]. Ryan Boyd presents each role’s responsibilities as following:
Resource server
The server that has the resources protected by OAuth. Typically the server holds the data and provides an API through which the data can be accessed.
Resource owner
Typically the user of the application. Resource owner gives their credentials and grants the client delegated access to owners data hosted on the resource server.
Client
An application that makes API requests to the resource server and performs authorized operations on the resource owner’s behalf.
Authorization server
The server that issues the access token to the client after getting the resource owner’s permission. The token is then used by the client to do protected operations.
Figure 6: OAuth 2.0 Authorization Code Grant Flow, Adapted from: [29]
- Resource owner accesses the application.
- Application asks the resource owner to authenticate and for permissions to access the requested resource on the resource owners behalf.
- Resource owner provides credentials for the authentication and consents to the authorization, which are passed on to the authorization server.
- Authorization server sends authorization code to the application.
- Application requests for an access token with the authorization code.
- Authorization server issues an access token to the application with permissions to access the resource on the resource owner’s behalf.
- Application requests the resource from the resource server.
- Resource server returns the resource for the application.
OpenID Connect
OpenID Connect (OIDC) is a protocol for identity federation based on OAuth2.0. It expands on OAuth2.0 with an identity and authentication layer. OIDC uses REST/JSON message flows that are common in web development, making it relatively easy for developers to use [30]. After authentication OIDC sends a JSON Web Token (JWT) to the application, which contains authentication information and user profile, which the application can use. For any authentication or authorization purposes, OIDC presumes five roles: End User, Relying Party, Authorization Endpoint, Token Endpoint and UserInfo Endpoint [31]. In Figure 7, OIDC authentication flow is presented.
Figure 7: OIDC Authentication Flow, Adapted from: [32]
- End user has accessed the application, which in this case is the relying party. Relying party requests the OIDC provider to authenticate the user.
- User authenticates and consents to the relying party getting access to the user’s identity.
- Authorization endpoint sends authorization code to the relying party.
- Token endpoint is requested with authorization code to give the user’s ID token and access token for the relying party.
- With access token the relying party can request userinfo endpoint for a userinfo claim which contains additional information of the user.
JWT tokens in OIDC messages contain an encrypted payload. The payload has key-value pairs that give important information about the token like who issued it, the audience of the token, who is the subject of the token, when the token expires and some user information. In many cases a token’s life cycle is relatively short and a refresh token is provided, which can be used to get a new access token without providing login information for a second time [33].
| { “iss”: “JWT Issuer”, “iat”: 1634892997, “exp”: 1666428997, “aud”: “www.oidc.example.com”, “sub”: “tony@example.com”, “GivenName”: “Tony”, “Surname”: “Example”, “Email”: “tony@example.com”, “Role”: [ “Admin”, “Student” ] } |
Figure 8: JWT payload example
User Directories
User’s identity information is at the heart of the IAM system. Typically, an IAM system connects to one or more user stores that host user information and attributes. Common operations done against user store include creating new entries, editing, searching, deleting, and retrieving entries. These operations are possible in any conventional database, but there are technology solutions called directory services developed specifically for these use cases.
Databases and directory services have similar capabilities such as fast searches and extendable schema. One of the differentiating factors between the two is that databases are designed to handle roughly the same number of read and write operations, while directories focus on read operations and assume write operations to be more rare [34]. This design focus can be seen in the performance and efficiency of operation. These wouldn’t make much difference in small numbers, but when operating with large datasets they become an important factor when choosing a suitable technology. Additionally user directories implement granular access control [35].
LDAP
Lightweight Directory Access Protocol (LDAP) is an open protocol for directory services accessible over the internet [36]. It is based on X.500 directory access protocol and developed to be a lighter version of that, using a simpler and nowadays more widespread TCP/IP protocol stack. LDAP-directories are often used to store user data, attributes, and credentials.
Being a protocol, LDAP doesn’t concern about what backend is used to store the data, but it specifies the schema and communication flows for managing it. The data is organized in a hierarchical tree-like structure starting from the root and spreading possibly across multiple levels of depth. Apart from the root element, each entry has a parent element and every child element has a unique attribute among its siblings called Relative Distinguished Name (RDN). Individual entries are retrieved by their Distinguished Name (DN). Entries DN is constructed from their RDN appended with their parents DN. In Figure 9, the user John’s DN would be uid=john,ou=people,dc=organization.fi.
Figure 9: LDAP hierarchy, Adapted from: [37]
Many vendors have developed their own LDAP-directories, some commercial and some open source.
Social Login
Social login has grown in popularity over the last decade. Internet giants like Google, Facebook, Apple and Twitter all offer their user information to be utilized by third party websites. This functionality is typically implemented by a login widget on a third party site that sends login information to the identity provider who authenticates the user and returns their information. Sites often provide social login as an option alongside traditional site specific registration and login. Benefits of social login are similar to the benefits of generic Single Sing-On, but with few differences. Some notable perks of implementing social login are:
Streamlined registration process
Normal registration requires users to spend time and effort entering required information to the application, leading to users dropping the process altogether [38]. Using social login can increase the number of registrations to a site.
Ease of use
As in generic SSO, users don’t have to remember multiple passwords to multiple different web-sites. This reduces reuse of passwords and enables users to have a single more secure password for their profile. Additionally, as social login is implemented by third party sites, users gain access to a large number of services across the web with a single account.
Better user information
Third party sites gain access to a verified email and not a fake address that are often used when registering to a web application. Also, users are more likely to keep their social network profiles updated, leading to more accurate and richer information for the third party application [39].
Reduced infrastructure costs
Owners of the site have significantly reduced the need for frequent maintenance of the authentication infrastructure. Leading to increased security and lowered costs for the owners over time [39].
Customer portal
Customer portal in CIAM refers to the web interface where user operations can be done. Usually, multiple portals are needed: a login portal, user portal, and admin portal. As the name suggests, the login portal would be used when logging in to applications and services protected by the CIAM system. User portal is for normal end users and their consent and account management. Admin portal is for management purposes used for administration by CIAM provider as well as management of tenants and their configuration by tenant admin. Important operations in customer portals are following:
- Account self-service: Users should be able to onboard and login to services by themselves and manage their user profile and consent information. Also, features like password reset, configuring MFA and linking social login information would be done here if the CIAM solution supports it.
- Tenant management: Tenant admin should be able to do management inside the tenant. Operations like connecting the system to applications, configuring user federation, managing user roles and permissions, and auditing events.
- CIAM management: CIAM provider should be able to manage tenants and their individual configurations from the portal.
Because the CIAM solution is intended to be used by a large number of end users, the scalability of the system is extremely important to ensure operation even during traffic spikes. This goes well with cloud infrastructure, where applications are orchestrated as micro services and scalability is a priority. As for user portals, self-service is a way to make the system scalable to more users without putting more pressure on CIAM administrators. It’s also essential in complying with data privacy regulations like General Data Protection Regulation (GDPR), which will be discussed in the following GDPR section.
Governance
Identity Governance and Administration (IGA) is defined by Andrew Cameron and Graham Williamson as including “the collection and use of identity information as well as the governance processes that ensure the right person has the right access to the right systems at the right time” [40]. In IAM, this covers the admin management events, processes and tools for governing operations in the system. In order for an IAM system to be governed well, the system needs to collect logs of events, analytics and metrics. These event logs and analytics should then be accessible to audit so that organizations can meet the compliance and regulation requirements [40].
GDPR
In 2018, European Union’s GDPR came into effect. It defines regulation for companies based in the EU and for companies that process data of people living in the EU area [41]. The legislation details controls for handling of personal data and gives data subjects rights, which the processor of data must comply with. As CIAM-solutions store and process personal data, they are subject to these regulations and designed to be compatible with them. This is one of the selling points of CIAM systems, since companies need to decide their strategy concerning identity management, and the modern CIAM systems can offer them a way to fulfill the requirements of regulation [42][43]. The key parts of the regulation from the CIAM systems perspective are the following [44]:
Consent (Articles 7, 8, 9): The data controller must seek and be able to demonstrate data subjects consent to process personal data. If the request for consent is done with a written declaration that also concerns other matters, then the consent must be distinguishable and given with an easily accessible form in clear language. Data subjects also have a right to withdraw their consent at any time [45].
Erasure (Article 17): The data subject has a “right to be forgotten”. Upon request, the data controller must erase all personal data regarding the subject without undue delay [45].
Rectification (Article 16): The data subject has the right to rectify any incorrect personal data without undue delay [45].
Data Access (Article 15): The data subject has the right to obtain confirmation whether their personal data is being processed or not. If the data is being processed, the subject can access the personal data, information about the purposes of processing, and the parties to whom the data is shared [45].
Portability (Article 20): The data subject has a right to receive personal data provided to a controller in a structured and machine readable format [45].
Security of processing (Article 32): The data controller and processor must implement technical and organizational measures to ensure that personal data is appropriately protected depending on the level of risk. One of the possible measures can be pseudoanonymisation and encryption of personal data [45].
CIAM systems help organizations fulfill these requirements, by moving from multiple different services with each their own user stores, processes and management systems into a single system. With a single system it’s much easier to manage personal data and processes in a secure and GDPR-compliant manner. The requirements regarding data access, portability, rectification, erasure and consent are often partly enforced via user self service portal. In the portal, users can see and edit their personal profiles and manage consent given to different services and revoke it if needed [43]. By delegating users to manage profile information, the data controller can alleviate some burden of administration while simultaneously fulfilling requirements set by the regulation. However, it is good to remember that these systems are only tools for management and need to be used and configured properly to ensure security and compliance.
Next: Cloud Technologies
Cloud computing is a model of where computing resources are provided on-demand via network access and can be rapidly provisioned and released with minimal management effort. To get full benefits of cloud computing, applications are typically divided into smaller micro-services and packaged into containers, which enable more flexible scaling compared to traditional methods. In this section of the thesis, important technologies enabling cloud computing are presented to give background information about how the services are run in the cloud.
With containers, Cloud Technologies provide an ideal technology platform for CIAM services. In the next part of this blog series we will explore these in more detail.
| [24] | Bhargav-Spantzel A, Squicciarini A, Bertino E.Establishing and protecting digital identity in federation systems. Journal of Computer Security, 2005. Vol 14:3. P. 11-13. DOI 10.1145/1102486.1102489. |
| [25] | Lewis K. Lewis J. Web Single Sign-On Authentication using SAML. IJCSI International Journal of Computer Science Issues, 2009. Vol 2. P. 41-48. ISSN (Online) 1694-0784. |
| [26] | OASIS, Security Assertion Markup Language (SAML) V2.0 Technical Overview. [Cited 2.9.2021]. Available at: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html. |
| [27] | Naik N, Jenkins P. Securing Digital Identities in the Cloud by Selecting an Apposite Federated Identity Management from SAML, OAuth and OpenID Connect. 2017 11th International Conference on Research Challenges in Information Science (RCIS), 2017. P 167-174. DOI 10.1109/RCIS.2017.7956534. |
| [28] | Boyd R. Getting Started with OAuth 2.0. 1st ed. Beijing, China. 2012. P. 80. ISBN 1-4493-1784-7. |
| [29] | VMware. OAuth 2.0 Grant Types. [Cited 8.9.2021]. Available at: https://docs.pivotal.io/p-identity/1-11/grant-types.html. |
| [30] | OpenID. Welcome to OpenID Connect. [Cited 28.6.2021]. Available at: https://openid.net/connect/. |
| [31] | Naik N. Jenkins P. An Analysis of Open Standard Identity Protocols inCloud Computing Security Paradigm. 2016 IEEE 14th Intl Conf on Dependable, Autonomic and Secure Computing, 14th Intl Conf on Pervasive Intelligence and Computing, 2nd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress(DASC/PiCom/DataCom/CyberSciTech), 2016. P. 428-431. DOI 10.1109/DASC-PICom-DataCom-CyberSciTec.2016.85. |
| [32] | OneLogin. Dev Overview of OpenID Connect. [Cited 20.10.2021]. Available at: https://developers.onelogin.com/openid-connect. |
| [33] | OpenID. OpenID Connect Core 1.0. [Cited 26.10.2021]. Available at: https://openid.net/specs/openid-connect-core-1_0.html. |
| [34] | Carter G. LDAP System Administration. 1st ed. Sebastopol, USA. 2003. P. 312. ISBN 0-596-51869-2 |
| [35] | Sheresh B, Sheresh D. Understanding Directory Services. 2nd ed. USA. 2002. P. 400. ISBN 0-672-32305-2 |
| [36] | Sermersheim E. Lightweight Directory Access Protocol (LDAP): The Protocol. [Cited 8.9.2021]. Available at: https://www.rfc-editor.org/rfc/rfc4511.txt. |
| [37] | GeoServer. Authentication with LDAP. [Cited 8.9.2021]. Available at: https://docs.geoserver.org/stable/en/user/security/tutorials/ldap/index.html. |
| [38] | Malheiros M, Preibush S. Sign-Up or Give-Up: Exploring User Drop-Out in Web Service Registration. Symposium on Usable Privacy and Security, 2013. |
| [39] | Wang R, Chen S, Wang X. Signing Me onto Your Accounts through Facebook and Google: a Traffic-GuidedSecurity Study of Commercially Deployed Single-Sign-On Web Services. 2012 IEEE Symposium on Security and Privacy, 2012. P. 365-379. DOI 10.1109/SP.2012.30. |
| [40] | Cameron A. Williamson G. Introduction to IAM Architecture. IDPro Body of Knowledge, 2020. Vol 1:2. Available at: https://bok.idpro.org/article/id/38/. |
| [41] | Council of European Union. EUROOPAN PARLAMENTIN JA NEUVOSTON ASETUS (EU) 2016/679, annettu 27 päivänä huhtikuuta 2016,luonnollisten henkilöiden suojelusta henkilötietojen käsittelyssä sekä näiden tietojen vapaasta liikkuvuudesta ja direktiivin 95/46/EY kumoamisesta (yleinen tietosuoja-asetus) (ETA:n kannalta merkityksellinen teksti). 2016. Available at: https://eur-lex.europa.eu/legal-content/FI/TXT/HTML/?uri=CELEX:32016R0679&from=EN |
| [42] | Ubisecure. General Data Protection Regulation & Customer IAM Considerations for GDP Compliant Services. [Cited 29.7.2021]. Available at: https://www.ubisecure.com/wp-content/uploads/2019/05/GDPR-and-Customer-IAM-Ubisecure-White-Paper-6.18.pdf. |
| [43] | WSO2. General Data Protection Regulation. [Cited 29.7.2021]. Available at: https://docs.wso2.com/display/IS550/General+Data+Protection+Regulation#GeneralDataProtectionRegulation. |
| [44] | Havelock C. How CIAM solves Key Technical Requirements of GDPR. [Cited 12.8.2021]. Available at: https://www.pingidentity.com/en/company/blog/posts/2018/how-customer-identity-access-management-ciam-solves-key-tech-requirements.html. |
| [45] | Council of the European Union. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance). 2016. Available at: http://data.europa.eu/eli/reg/2016/679/oj |
