Adaptive security architectural model for protecting identity federation in service oriented computing

Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

Contents lists available at ScienceDirect

Journal of King Saud University – Computer and Information Sciences journal homepage: www.sciencedirect.com

Adaptive security architectural model for protecting identity federation in service oriented computing Mohamed Ibrahim Beer Mohamed a,⇑, Mohd Fadzil Hassan b, Sohail Safdar c, Muhammad Qaiser Saleem d a

Department of Computer & Information Sciences, Universiti Teknologi PETRONAS, 32610 Seri Iskandar, Perak Darul Ridzuan, Malaysia Center for Research in Data Science (CeRDaS), Universiti Teknologi PETRONAS, 32610 Seri Iskandar, Perak Darul Ridzuan, Malaysia. c Department of Information Technology, College of Information Technology, Ahlia University, Manama, Bahrain d College of Computer Science and Information Technology, Al Baha University, Al Baha, Saudi Arabia b

a r t i c l e

i n f o

Article history: Received 7 October 2018 Revised 6 February 2019 Accepted 4 March 2019 Available online xxxx Keywords: Federated identity SSO Security SOA EAI Trust

a b s t r a c t With the tremendous growth of Internet and its related technologies, the Service Oriented Architecture (SOA) became a dominant paradigm shift for enterprise computing. In SOA, business functionalities are offered by many different Service Providers as services. In order to get served by different service providers, the client has to authenticate with those service providers at multiple times. Single Sign On (SSO) mechanism provides the client to login only one time so that access to different services is made possible without needing to re-authenticate. Here, the identity of the logged-in client is federated among the enterprise computing nodes. This is one of the simplest forms of federated identity. The goal of identity federation is to benefit ease of use, flexibility, productivity and reduced cost of the authentication process, but trust and security is a major concern in this situation. Major threats on federated identity management are due to identity misuse, identity theft, and trust deficit between identity providers and services providers. As of now, the Security Assertion Markup Language (SAML), Open Authorization (OAuth) and OpenID are the three important federated identity management standards in the industry. However, none of them is equipped by itself to provide comprehensive security protection for identity federation even within a single enterprise computing environment. In fact, these federated solutions result in additional security vulnerabilities due to their openness of identity federation. The security threats are becoming severe when federated identity is spanned into the inter-organizational and intraorganizational computing environment. This paper analyses the vulnerabilities and security gaps in the existing federated identity solutions. To overcome these gaps, an adaptive security architectural model is proposed for identity federation at inter and intra-organizational level using public key infrastructure that adheres to the SOA security standards and specifications. The proposed architecture is implemented and tested in a large-scale federated identity enterprise computing environment with security-centric financial data to acquire the desired results. A cross-sectional comparative analysis is done between existing and proposed solutions to validate the improvement in the protection of identity federation environment. Ó 2019 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

1. Introduction ⇑ Corresponding author at: B-06-3A Millennium Square, Jalan 14/1, Seksyen 14, 46100 Petaling Jaya, Malaysia. E-mail addresses: [email protected] (M.I. Beer Mohamed), [email protected] (M.F. Hassan), [email protected] (S. Safdar), muhammad.qaiser. [email protected] (M.Q. Saleem). Peer review under responsibility of King Saud University.

Production and hosting by Elsevier

In an Enterprise Computing environment, the identity federation is a security model that supports users to log into different interconnected systems using a single set of registered sign-on credentials, regardless of the infrastructural and implementation technologies. Thus, the Federated Identity Management (FIM) simplifies the authentication process for subscribers who can access all the privileged application services and hardware systems of the entire enterprise by signing in a single time. The Single Sign On (SSO) is one of the implementations of FIM at an enterprise level, which is a well-recognized methodology in the

https://doi.org/10.1016/j.jksuci.2019.03.004 1319-1578/Ó 2019 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

2

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

security domain. SSO is an efficient way of accessing different services used within the same enterprise. However, federated identity management system makes use of SSO and aims to provide single access to multiple systems across different enterprises. SSO can be implemented using numerous single authentication credential approaches such as user id/password, smart card, One Time Password (OTP) and biometric device identification. Generally, all of these authentication approaches fall into two categories: Password-based synchronization and Ticket based access. The password based synchronization uses a single password that should be used for accessing multiple systems. It is not a preferred choice in most of the enterprises because if an attacker succeeds in obtaining the password while accessing any one of the systems, then it leads to the accessibility of any other systems in the underlying SSO region with the same authentication credentials. As an improved approach, the centralized password database persists the passwords of the users for multiple systems and provides a master password to a user who can login to any of the systems within SSO region, where the SSO module does a lookup on required password in the database for an underlying system to log in. Even this approach cannot prevent eavesdropping and replay attacks (Saadeh et al., 2016; Ling et al., 2017). Compared to password-based synchronization approach, token-based SSO approach is more secure as these tokens will only live for a predefined time interval which prevents reply attacks. However, it requires clock synchronization between underlying servers and clients which is an additional overhead. Modern Enterprise Application Integration (EAI) solutions are positioned at the wheels of cloud computing, where it provides resource pooling, broad network access, measured services, horizontal/vertical scalability, and on-demand services to enterprise users. Hence, cost and effective usage are the core features of cloud computing, but trust and security are the topmost concerns. Federated identity solutions also face challenges in authentication and authorization process that include, misuse/theft of user identifications, eavesdropping the session tokens and the trustworthiness of logged in users. Identity theft is one of the major concerns during security breach as it is very difficult to detect it before the actual harm occurred (Mainka and Mladenov, 2016). Moreover, we cannot assume that this theft will only occur on the unsecured channel. In case of any identity attack in federated identity-based multi-server environments due to the intensive usage of distributed computer networks, cellular networks, peer-to-peer networks, virtual connections and Word Wide Web connections, the organization has to ensure privacy by local legal compliance and security assertions. The Service Oriented Architecture (SOA) became very dominant in the current generation of Enterprise Application Integration (EAI) era. In SOA, the business functionalities are decomposed into small software modules, called services. Each service is treated as an independent component and does not depend on the context of other services. These services are hosted by different service providers within the organization. These services can also be spanned to the inter-organizational environment based on the requirements and demand of services. In this enterprise application integration, each service provider expects the user (client application) to authenticate itself to gain access to services based on the privileged authorization. Practically, it is not a feasible solution to login with each service providers whenever the client wants to access their services. Here, the federated identity management became handy and resolves the multi-sign on problem, but introduces additional identity-based vulnerabilities to SOA. Moreover, SOA by itself does not possess adequate security solution and its security is totally dependent on network/transport layer security assertions (Masood, 2015; Yarygina, 2018) as SOA uses basic transport layer protocols such as HTTP/HTTPS and plain data exchange for-

mats such as XML/JSON to achieve platform and machine architecture independence. Hence the design of security solution for federation identity on SOA should be thoroughly reviewed and at the same time, it should not breach the standards of SOA specifications. In this paper, security gaps are analyzed for existing federated identity management solutions as discussed in Section 2. An adaptive security model is proposed as a comprehensive federated identity management solution. The proposed model is equipped with adequate security which works for both single and interorganizational cloud-based enterprise computing environment. The methodology and functionality of the proposed architecture are illustrated in Section 3. Section 4 discusses the implementation and validation analysis of the proposed solution. Sections 5 and 6 conclude the paper with a discussion on future work. 2. Context and motivation Cloud computing is an evolution of grid computing, and it emerged as an influential paradigm for developing and delivering internet-based business services for enterprises. In this modern era of enterprise computing, everything becomes as services where the end user has to communicate with many service providers for achieving the desired business transaction. Considering a banking operation, there are different service providers within the same bank for various operations such as core banking, transaction banking, retail banking, card operations, cash management, loan management, transfers, payments, standing instructions and customer service, but all of these services are available to the user once he/she has successfully logged-in to eBanking application once. In addition, the banking customers are allowed to navigate for other specialized services such as interbank account management, credit scoring with the central bank and international fund transfer that these services are provisioned by other third-party service providers but available to the logged-in user without requesting for a separate login. This flexibility and ease of use features are possible because of the federated identity mechanism. The following subsections outline the identity federation principles with a reference to Single Sign On functionality, a brief introduction on the existing FIM solutions, security gaps in the existing identity federation, and the motivation behind the conducted research in the review of available literature. 2.1. Single Sign On: identity access management The SSO is an authentication mechanism that enables federated identity within the trusted computing entities in an organization, Circuit of Trust (CoT), enabling the user to sign-on one time and access the privileged services from various service providers in the same session. Among the available authentication and authorization protocols in the market for federated identity, only three protocols are well received and competitive: SAML, OAuth and OpenID. All of these three protocols differ in providing authentication/authorization and addressing security concerns of exchanging privileged data, but at the bottom level all three follow the same working principle: token based federated identity. A cookiebased token SSO access management flow is depicted in Figs. 1 and 2 respectively for first-time access of Service Provider (SP) by the user and successive accesses to the same SP/other SPs within the CoT. When the user is attempted to access any service provider for the first time or after the expiry of the previous login due to logout, expiration of session or timeout, the user is redirected to Identity Provider (IdP)’s login page for authentication. Once the login process is successful, the IdP will provide the token (certificate) to any accessed service providers (SPs) who will verify

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

3

are handled by the following authentication mechanisms, along with token generation. a. Validation on Credentials: i. Username/Password check against internal database table or centralized database table ii. LDAP authentication against organization’s directory service providers like Active Directory iii. Authentication check with external SSO systems b. Validation on Tokens: i. Token received from partner site SSO ii. Referrer URL with Token parameter iii. Check on Clock synchronization and Token validity duration 2.1.2. OAuth OAuth (OAuth, 2018) is an Open Authorization protocol which provides secured delegated authorization service. It supports the applications to obtain limited access to other applications without giving away user’s password. This protocol does not deal with authentication, it simply connects to the Authentication server to get token for a service accessed. In OAuth terminology, Service Providers are called as Resource Servers, Identity Provider is referred as Authorization Server, and the User is called as Resource Owner. Let’s take an example of importing contacts from Gmail account to LinkedIn, where both of them are resource servers. Fig. 1. Cookie-based SSO Flow: First-time access by the user.

1. User logged in to LinkedIn successfully and chosen the option to import all his/her Gmail contacts into LinkedIn. 2. Then the user is redirected to Gmail page and asked for a login. 3. After the user logged in to Gmail using Gmail credentials, it will prompt the user whether he/she is willing to grant LinkedIn resource server on reading his/her contacts data. 4. If the user agrees to grant the permission, then Gmail will provide authorization token to LinkedIn on one-time access to user’s contacts. Then, LinkedIn will import the Gmail contacts. Here, the OAuth’s role is to provide delegated access on Gmail to LinkedIn.

Fig. 2. Cookie-based SSO Flow: Consecutive access by the user.

the token and provide access to the particular user. In this case, the user is required to login only once for accessing services on multiple service providers. 2.1.1. SAML The Security Assertion Markup Language (SAML) (SAML, 2018) is a widely accepted standard for Single Sign-On assertion, used for exchanging authentication and authorization data between IdP and SPs. In the token based SSO, trust is important between IdP and SPs where all the underlying SPs agree to trust the connected IdP to authenticate users. At the IdP, the SSO assertions

Looking at the given example as above, the user is not providing Gmail login credentials to LinkedIn, but a onetime delegated access. Otherwise, the LinkedIn can access all the services of Gmail including private emails with the provided login credentials. In OAuth technical flow, the client application will receive two tokens namely Access Token and Refresh Token from the Authorization Server once Resource Owner is successfully logged-in through the redirected URI. Then the client will pass the access token to Resource Server for accessing the protected resource. For security reasons such as to avoid token theft, the access tokens are short lived. The client will use refresh token to get a fresh access token from Authorization Server upon expiry of previous access token without re-login. Refresh tokens are also having expiry period, but long-lived. 2.1.3. OpenID OpenID (OpenID, 2018) can be considered as an authentication layer on top of OAuth. First, the user must have an OpenID account with any of an OpenID identity provider. Then, the logged in user on this IdP can get accessed to privileged services directly at resource servers (aka relying party) that accept OpenID authentication. The OpenID will redirect the underlying user to IdP (aka OpenID Provider) for authentication while accessing a relying party’s service and if the user is successfully authenticated through login credentials or active SSO session, then IdP redirects back to that service with authorization. OpenID is about who the user is and OAuth is about what they are allowed to do.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

4

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

2.2. Security gaps in existing FIM An efficient access control mechanism is claimed as a critical entity for the successful implementation of federated identity management system, which caters for the following three important information security demands: a. Confidentiality: assurance for keeping the information (services) to be kept secure and private. b. Availability: the information will be available for use when needed. c. Integrity: Keeping the information accurate and consistent. Unfortunately, the FIM implementations using existing technologies such as SAML, OAuth and OpenID are still limited in providing comprehensive security for federated identity solution. Existing solutions have certain shortcomings in security and architectural perspective (Malik et al., 2015; Chen and Liu, 2015), such as (i) introducing additional vulnerabilities that can be exploited by attackers, (ii) facing time synchronization issues between SP and IdP, (iii) experiencing higher infrastructure cost, (iv) experiencing lower efficiency and network latency and (v) having insufficient control to preserve user’s anonymity. Thus, designing a comprehensive and efficient federated identity solution for accessing services on distributed networks in this era of enterprise application integration is difficult and challenging (Ouaddah et al., 2017; Sharma et al., 2016). The following are the major implementation challenges while going for federated identity solution for an enterprise computing environment.
Dependency on IdP’s Authentication Mechanism: In SSO, service providers of the same group trust on the token provided by an Identity Provider, means all of these SPs trust uniformly on the single authentication mechanism insisted by IdP. Suppose some of these service providers desire to have a strong authentication such as smart cards and biometric crypto validations that are not supported in IdP, then this centralized IdP functionality became practically infeasible.
Clock Synchronization Overhead: In order to prevent the replay attacks, usually a timestamp is applied in the SSO communication. The clock synchronization is mandatory between servers and clients for this timestamp-based SSO mechanism. Practically, it is an overhead process of keeping the clocks of engaged servers and clients being synchronized at all the time. A good federated identity system should not demand clock synchronization but still prevents replay attacks.
Single Point of Failure: If the SSO provider goes down, then all the underlying users will not be able to authenticate so that they cannot benefit with any service, resulting in Single Point of Failure.
Identity Theft and Platform Trustworthiness: If the IdP is hacked or breached, then the hackers can enjoy in accessing services in service providers as legitimate users. Identity theft and misuse of identity are noticeable issues in the federated identity environment.
Security Vulnerabilities with OpenID: The OpenID standard uses symmetric key cryptography and HTTPS session for secure transaction. Definitely, symmetric cryptography is more vulnerable than asymmetric cryptography and HTTPS is totally inadequate for secure conversations on the latest web technologies such as Web 2.0 and Web 3.0. A successful Man-inthe-middle attack can reveal the identity in this approach. Even when the authentication validity with OpenID Provider (OP) is expired, the provided authenticated status with Resource Provider (RP) will be still valid. It is dangerous if the attacker captured the valid session on the client who

was accessing with RP and trying to consume the services on RP as the connection is still valid. The following are the potential security vulnerabilities and attacks that the enterprise users are encountering now with the existing federated identity systems (OWASP, 2017; Islam et al., 2016; Simpson and Groß, 2016; Almorsy et al., 2016; Mahmoud et al., 2015).
Replay Attack: Many Resource Providers do not check on nonce values which are embedded with the requests to RP for resisting replay of requests. Even if RPs are enriched in validating the nonce values, the intruder succeeds by initiating replay attack at the server side.
Phishing Attacks: A compromised RP redirects to a phished IdP page where the attacker captures the user credentials. The intruders manipulate the communication channels as legitimate IdP and lure the federated identities.
Impersonate Attack: A hacker gets the access to a service provider by sniffing the network packets and acquiring the service provider’s details. In SAML based implementation of SSO, XML Signature Wrapping lead to impersonate any user.
Denial of Service (DoS)/Distributed DoS/Repudiation Attacks: The IdP is stressed by attackers with overwhelming false authentication/authorization requests, trying to either halt the IdP servicing or make the service delayed to disturb its Service Level Agreement (SLA). Repudiation attack occurs when the malicious user denies responsibility of an action that he/she had performed to interrupt the operation, but there is no proof on such action without appropriate auditing.
Data Tampering Attacks: Unauthorized modification of identity information persisted at IdP database using any loopholes due to insufficient integrity.
Network Eavesdropping Attack: It is not always assured that the identity data are traveled through secured channels for federated identity management, where the data packets are transmitted through both secured organizational and unsecured public networking environment. With this network eavesdropping, the attacker captures identity information by intercepting data packets over the targeted network communications.
Identity Forgery/Spoofing/Cloning Attacks: Imitating like a legitimate identity for purpose of benefiting services offered by service providers.
Privilege Elevation Attack: The SSO users of limited privileges increase their access rights illegitimately by impersonating higher privileged users in order to access unauthorized services.
Luring Attack: It is a specialized form of elevation of privilege attack, the user who obtains the higher privilege rights by impersonating higher rolled user unknowingly executes the code fragments of the attacker in the higher privileged security context.
Brute-force/Dictionary Attacks: With brute-force attacks, the attacker attempts to retrieve the persisted identity information at IdP using every possible combination of user id and password. A dictionary attack is a narrowed-down process of brute-force attack which uses the precompiled list of options which are likely to match. Even though this kind of attacks can be restricted by setting up maximum login attempts, the attacker aims to simply lock the legitimate user to do not get served at least.
Side-Channel Attack: In federated identity management, the IdP is the core unit that maintains confidential information about user credentials and token information. If this unit does not adhere to proper access control and security mechanisms, the intruders will try to steal the confidential information using the security vulnerabilities.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

5

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Table 1 Mapping of security shortcomings with characteristics of the expected solution. Short Comings

Vulnerabilities

Implementation challenges

Characteristics of the expected solution

Time Synchronization

Session Attacks; Cloning Attacks

Clock Synchronization Overhead

Infrastructure Overhead

Side-Channel Attack; DoS/Repudiation Attacks

Single Point of Failure

Network Latency

Network Eavesdropping Attack; Data Tampering Attacks

Single Point of Failure

Insufficient Control

Luring Attack; Snooping Attack; Man-in-the-middle Attacks; Privilege Elevation Attack; Impersonate Attack; Identity Forgery/Spoofing Attacks Replay Attack Phishing Attacks Brute-force/Dictionary Attacks

Dependency on IdP’s Authentication Mechanism; Identity Theft and Platform Trustworthiness Identity Theft and Platform Trustworthiness; Vulnerabilities with OpenID

Vertical/Horizontal Scalability; High availability with a fall-back High availability with fallback; Cost-effective solution Reduce re-authentication; Network infra compliance Modern and legacy security standards

Additional Vulnerabilities


Snooping Attack: It is a specialized version of network eavesdropping that uses more sophisticated snipping techniques to extract the required information from the illegitimate collection of sensitive security and infrastructure data such as network topologies, service dictionary, applied security algorithms and server locations.
Man-in-the-middle Attacks: The SSO implementations are prone to man-in-the-middle attacks as the identity tokens are passing through multiple networks. All these networks cannot be secured at all time as identity may be federated to crossorganization environments which are connected through public communication channels.
Session Attacks: As there may be many active sessions in a federated identity environment, hijacking one active session is enough for an attacker who can access all the authorized services scattered among multiple service providers. Some session related attacks that could happen in federated identity management include Session Swapping, Cross-Site Request Forgery (CSRF) and Cross-site Scripting (XSS). An ideal federated identity management system should possess the following characteristics to address the formerly mentioned security gaps. a. Allows horizontal and vertical scalability of enterprise computing systems. New hardware and software applications can be easily installed and configured for SSO. b. High availability on SSO functionality with fallback mechanisms. c. SSO implementation should not breach any industry defined security standards. The SSO should address both modern and legacy enterprise systems authentication needs. d. A minimum number of re-authentication for a user in FIM. Consecutive attempts to multiple service providers with different IdPs should not prompt for re-login. e. IdP should use strong encryption protocols for persisting credentials. f. IdP should enforce strong authentication, but at the same time supporting all kind of network infrastructure. g. Extend the comprehensive SSO functionality to remote users even through VPN. h. SSO solution should be a cost-effective one and should not be a time-consuming process. The mapping of listed shortcomings on existing federated identity solutions with security vulnerabilities and their implementation challenges along with how they can be addressed in the

Strong encryption protocols; Comprehensive solution

expected comprehensive security architectural model is presented in Table 1. 3. Proposed security architectural model Overcoming the vulnerabilities and security gaps in identity federation system in SOA, an adaptive security architecture is proposed that can provide the comprehensive security for identity federation. For achieving desired security objectives, an algorithm is devised for the effective implementation of proposed adaptive security architecture in SOA. The proposed security architecture is constructed on the basis of Public Key Infrastructure (PKI) to make use of secure access control, mutual authentication and secure over the air (OTA) update along with other supporting security technologies. Since PKI is a well-established set of rules and policies, therefore the proposed solution adheres to the standards and specifications of security based on PKI. Moreover, it does not require any specialized hardware and software except the configuration for message interpretation. The following subsections describe the core component and underlying security models in detail for the implementation of proposed security architecture in the enterprise computing environment. 3.1. Intelligent security engine: the core part of proposed security The proposed security algorithms are encapsulated on a software module named ‘‘Intelligent Security Engine (ISE),” which is a novel pluggable security component that can be attached or detached to any computing node in federated identity environment with simple configuration, without altering the source code of underlying Service Oriented Architecture (SOA) implementation as ISE follows on Aspect Oriented Programming (AOP) techniques. A typical placement of ISE as a central node of SOA network is shown in Fig. 3, however an ISE can be placed at any computing node as required, where its functionality remains the same. With this introduction of ISE in the SOA network, the federated identity will be governed by ISE enforcing security. If detached, the federated identity will still operate in the usual manner. In both of the cases, identity federation service will not be interrupted, and those computing elements that are not part of ISE surveillance security will continue to be served as default. The intelligent part of ISE is enriched with supervised knowledge acquisition process of Artificial Neural Networks (ANN) on detecting security threats of federated identity for SOA in secured and unsecured communication channels. The ISE follows Interception Design Pattern on message inspection/filtration and works

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

6

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

program which is not related to any specific part of that program but providing cross-cutting requirements such as applying security. The ‘‘advice” is the action that should be taken for an aspect. The ‘‘joinpoint” is a point in the control flow of application execution such as method call and field access and a ‘‘pointcut” refers to one or more joint points where an associated advice should be executed. With this, we implemented the proposed security algorithm as an advice on the security aspect that will be applied on message intercepting pointcut. 3.2. Proposed security models The developed security algorithm on defending federated identity management against its potential security threats is explained in this section with three segregated groups, for simplicity of illustration and understandability. Fig. 3. ISE is placed as the central node in SOA Network.

based on Rule-based Engine (RBE) for fraud detection/prevention. The complete design of ISE with ANN supervised learning for securing SOA is presented as a paper (Ibrahim and Hassan, 2016) by the same authors, where the security solution is provided as an adaptive way forward on Internet of Things (IoT) that includes three phases in a cyclic manner: (i) Predict: predicting the potential threats on SOA environment by using the developed theoretical security model, (ii) Prevent: defending against the security threats using the constructed security algorithms and (iii) Learn: upgrading the threat knowledge database using neural nets, as shown in Fig. 4. In this paper, we restrict ourselves to present a security solution defending against security attacks in FIM which falls under ‘‘prevent” part of our original adaptive security architecture. As the security components in the proposed solution are programmed using Aspect Oriented Programming rather than traditional Object Oriented Programming (OOP), it decouples security implementation from the underlying business logic of services. Thus security is treated as a pluggable component which can be attached/detached with no or very minimal code changes on the service implementations (Kumar, 2016; Jain and Gopalani, 2016). While OOP mainly focuses on code modularization on reusability, AOP concentrates on application modularity by encapsulating cross-cutting concerns. In enterprise application integration code, the security-related cross-cutting concerns are scattered throughout the application logic such as access control, transaction management, input/output validation, and message interpretations. In AOP terms, an ‘‘aspect” refers to a feature in the application

Fig. 4. Core parts of Adaptive Security Architecture.

3.2.1. FIM with single IdP It is a simple enterprise application integration environment, where all the service providers trust with a centralized single Identity Provider. The proposed solution enforces two-factor authentication (2FA) for accessing services. The advantage of this 2FA is not only to strengthen the secure access of services but also avoids reauthentication with IdP when the user session became invalid. In this architectural model, all the user interactions on federation of identity are handled by the security component: ISE, but the existing functionalities of FIM components are kept intact, such as trust between IdP and SPs (Circuit of Trust). The proposed architectural model with single IdP federated identity management is outlined in Fig. 5. The secured identity federation with ISE for EAI works as following. 1. When a client (user) wants to access a service which is provided by one of the service providers, it requests ISE to connect to the particular SP. 2. ISE verifies the client’s session whether it is already logged-in with ISE or not. a. If not, then it prompts the user for authentication with ISE (1-factor authentication). b. If yes, proceeds to the next step. 3. ISE looks in its authentication lookup table whether the client has a valid session with IdP.

Fig. 5. ISE with Single IdP Environment.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

7

a. If no entry found in the lookup table or the corresponding Refresh Token is expired, then redirect the client to the authentication page of IdP for login (2-factor authentication -2FA). Once the client is successfully authenticated with IdP, make an entry in the authentication lookup table. b. If entry found in the lookup table and the corresponding Refresh Token is still alive, then check for its Access Token whether it is still alive or expired. If the Access Token is expired, then obtain a fresh Access Token from IdP using the Refresh Token and update in the lookup table.

eration occurs at the inter-organizational level. The proposed architecture is constructed not only to enforce security but also enriched with IdP linking service so that identity federation takes place automatically for FIM environment with multiple IdPs without going through re-authentication. With this novel feature, a client who has trust with one IdP can access any privileged services at SPs that have trust with other IdPs. The proposed security architecture for this type of FIM follows the same security principle as suggested for FIM with single IdP but enriched with IdP linkage feature as given below.

Cross Reference: The authentication lookup table in the database has the following fields.

1. A client (user) requests ISE to connect to a service at SP by providing SP id. 2. ISE authenticates the client (1FA). 3. ISE collects the list of IdPs that the given SP trusts with, through its broker service. 4. ISE looks in its authentication lookup table whether the client has a valid session with any one of the listed IdPs. a. If no entry found in the lookup table or all of the corresponding Refresh Tokens of IdPs are expired, then perform 2FA with first IdP and then insert/update an entry in authentication table with linkage service option as chosen by the user. b. If entry found, then look for an active Access Token in any one of the matched entries with Refresh Tokens are still alive. If all of the matched access tokens are expired, then obtain fresh Access Token(s) from IdP(s) using alive Refresh Token(s) and update them in the lookup table.

Client Id

IdP

LOA

Access Token

Refresh Token

The Level of Assurance (LOA) represents authorization level of underlying client to access the services in the SPs. Up to four LOA levels are followed that are recommended by National Institute of Standards and Technology (NIST) (Burr et al., 2004), where level 1 is the weakest and level 4 is the strongest. For example, the client has only read authority on the services with level 1 and can do both read and write with level 3. Both Access Token and Refresh Token are generated by IdP during 2FA where the client can use Access Token with SP for accessing services and the Refresh Token can be used to get fresh Access Token from IdP as Access Tokens are short-lived and Refresh Tokens are long-lived in FIM environment. 4. ISE encrypts the Access Token with defined hashing algorithm and passes the resultant hashed string as Transaction Token along with the client’s request to its own transaction agent, Session Broker. The Transaction token contains additional information for accessing service such as LOA. 5. The Session Broker Agent intermediates between ISE (for responding back to the client) and Service Providers (for consuming services). The agent publishes the client’s request along with Transaction Token and Digital Certificate of ISE on the Topic (Messaging Service). The Digital Certificate of ISE is attached to provide the Service Providers a trust that the request is coming from a valid source. 6. As all SPs are subscribed to agent’s messaging service, they will listen to the published request. 7. If anyone of the SPs detects that this request can be serviced by it, then it notifies the ISE Agent and accepts the request. Simultaneously, ISE Agent will create a dedicated thread (broker) connection with the particular SP to handle the communication in regard to service consumption. 8. The underlying SP will parse the received request and verifies the attached Digital Signature against ISE to ensure the request is coming from a valid source. If this check is successful, then it will validate the transaction token with its connected IdP. 9. As IdP is also maintaining the Access Token generated for SP under its region, it will use ISE’s service to get hash value by passing its access token. Then, this hash value is matched against the received transaction token. If both matches and the token is valid, then IdP will signal SP to proceed servicing for the request on LOA. 10. The SP will provide service or otherwise based on IdP’s validation on the received transaction token. The established broker thread will be closed at the end of service by ISE Agent. 3.2.2. FIM with multiple IdPs It is a complex enterprise computing environment, where one SP establishes trust with multiple IdPs. In such a case, identity fed-

Cross Reference: The sample entries in the database lookup table are as in Table 2. A client (user) may have authentication accounts with multiple IdPs in an inter-organizational EAI environment. Successful authentication attempts with these IdPs by the users at different time periods through ISE redirections will be recorded in the authentication lookup table. The Linkage Service option provides flexibility for a client to consume services available with SPs who are not directly trusted with IdPs in which the underlying client has authentication accounts. For example, assume that the client ‘‘User2” has only authentication account with IdP1, already authenticated with IdP1 and have valid Access Token in our lookup table with ‘‘Linkage Service” option is set to ‘‘Yes”. Now the client ‘‘User2” wants to access a service at SP2 which trust only IdP2. In this case, ISE sends the Transaction Token (encrypted version of Access Token) of IdP1 with Linkage Service option as enabled on the request to SP2 via ISE Agent. Then, SP2 requests its trusted identity provider IdP2 to validate the received transaction token (of IdP1). Here, the IdP2 will act as SP which communicates with IdP1 on validating the transaction token and then forwards the validation result to its client SP2. The SP2 will provide the service to ‘‘User2” based on the received validity information. In this example, if the ‘‘Linkage Service” is set to ‘‘No”, then the client ‘‘User2” cannot consume the requested service at SP2 unless the user has authentication account with IdP2 and successfully logged-in. 5. ISE attaches the encrypted version of chosen Access Token and other relevant parameters such as Access Token’s IdP, LOA, Linkage Service option and ISE’s Digital Certificate with the client’s request and forwards it to the required SP on a dedicated connection thread. 6. The underlying SP extracts the Digital Certificate for verification. 7. The underlying SP verifies the Digital Certificate which is attached with received request to confirm whether the request is coming from a valid source.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

8

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

Table 2 Sample lookup table entries. Client Id

IdP

LOA

Access Token

Refresh Token

Linkage Service

User1 User1 User1 User2

IdP1 IdP2 IdP3 IdP1

3 3 2 2

ABC GHI MNO STU

DEF JKL PQR XYZ

Yes Yes No Yes

8. Upon successful verification of ISE’s Digital Signature, SP checks whether it has a trust relationship with the Access Token’s IdP. a. If yes, it validates Transaction Token with the IdP. b. If no, it checks whether the ‘‘Linkage Service” parameter is set as ‘‘Yes” for this request or not. If Linkage Service is set as ‘‘Yes”, then it forwards the transaction token to any of its trusted IdPs which is configured and can serve for linkage service, to validate the token with its originating IdP. In this case, SP also sends an additional parameter named ‘‘Linkage Proxying” which is set to true, to the chosen IdP. If the Linkage Service is set as ‘‘No”, then SP denies the client to access service for the received request. 9. The IdP parses the transaction token validation request from SP. a. If no Linkage Proxying parameter is found or Linkage Proxying is set to false, then IdP fetches the Access Token which was generated for the particular client (from its maintenance table as all IdPs are maintaining the generated tokens for their clients). Then, this IdP uses ISE’s service to get encrypted value for this fetch access token. If both this encrypted value and transaction token matches, then IdP will signal SP to proceed servicing for the request on LOA. b. If Linkage Proxying is set to true, then IdP forwards the transaction token to its originating IdP and requests to do validation. Then, it forwards the received validation result to SP so that SP will provide service to the client when the validation is successful, or SP will refuse for service otherwise. 10. The established broker thread will be closed at the end of service by ISE Agent. The identity federation can be considered as a business model where a group of computing entities binds themselves with trustworthiness. An identity federation with single IdP is mathemati-

where SPik is kth service provider under ith CoT of FIM, which establishes restricted trust relationship while connecting to an idP on jth CoT of FIM by default. The same transitive trust level continues as identity is federated with multiple CoT. 3.2.3. Dynamic trust of SPs in IdPs The FIM operates on Circuit of Trust (CoT) that is, all the SPs are trusted with concerned IdPs and the clients have authentication accounts with those IdPs. Even with the Linkage Service that is proposed in the earlier subsection, federated identity is possible only if the SP’s trusted IdP in turn, trusts with IdP where the client is authenticated with. Consider a scenario that an eBanking client application of ABC bank wants to check on hire purchase loan details for its customers with core banking application of XYZ bank for credit scoring (core banking of XYZ bank is intended to provide service to other banking clients as part of the credit scoring scheme of central bank), where ABC and XYZ are two different organizations that they are not part of inter-organizational federated identity environment as either bank does not trust on IdPs of other banks. Also, either bank is not ready to include the clients of other banks to have authentication accounts with their IdPs. Federated identity solution is proposed to cater to the above kind of scenarios in which the required untrusted SPs are dynamically included with CoT temporarily using policy assertions. In our credit scoring scenario, the service provider (core banking application of XYZ bank) which is an untrusted SP to ABC Bank will be temporarily included in the CoT of ABC bank on the basis of defined central bank’s interbank policies. The proposed dynamic trusting of service provider model is depicted in Fig. 6. The dynamic trust model for including an untrusted service provider into the circuit of trust for identity federation works as following.

DT:f

cally modelled (Ferdous et al., 2015) as idP $ spi , where f 2 FIM, FT

idP 2 IdPs(f) and SPi 2 SPs(f). The idP is the identity provider of Federated Identity Management system f has Direct Trust (DT) type relationship with its service providers SP, hence communication between idP and any of these service providers SPi is FullyTrusted (FT). To achieve identity federation at the inter-organization level, the proposed linkage service makes an IdP in one CoT to act as an SP in order to communicate with another IdP in different CoT, as derived below. Each idP has full trust relationship with a list of SPs within CoT DT:f i

as idP i $ spij , where fi 2 FIM, idPi 2 IdPs(fi) and SPij 2 SPs(fi) for i 2 FT

{1,2, . . .n}. One idP has a full trust relationship with another idP DT:f fi;jg

within trusted FIM between fi and fj CoT as idPi $ idpj . The tranFT

sitive trust between two different CoT defaults to RESTRICTEDTRUSTED (RT) with Indirect Trust (IT) mode in FIM. A trust relationship of an SP within one idP’s CoT with another idP in different CoT is modeled as below.

     DT:f fi;jg DT:f fi;jg DT:f i idPi $ idpj ¼ SPik $ idpj SPik $ idpi FT

FT

FT

Fig. 6. Dynamic Trust Model for including untrusted SP in CoT.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

1. A client (user) requests ISE to connect to a service at SPx by providing SP id, where SPx is not present in CoT of user’s federated identity. 2. ISE confirms by checking with its configuration that SPx is not in the scope of CoT. 3. ISE starts Trust Negotiation process with SPx through WS-Trust. Cross Reference: The trustworthiness between these two entities is established based on defined policies. If the external entity satisfies the policies of an internal entity, then the external party is trusted by the internal party to join with CoT. The dialogs between both the entities are held at multiple times in order to provide and receive policy/authentication data. The assertion policies on trust between these entities vary according to the organizational security policies and legislation. Considering our credit scoring scenario, the service provider of XYZ bank offers its service to anyone who satisfies its policies, for example, it expects that the requester should be a banking client, whose trusted IdP should also be trust certified by the central bank. For ISE’s perspective, it will allow any SPs to join temporarily with CoT if the SP satisfies the policies of any IdP within the ISE’s region. For example, the SP should be a bank’s service provider, who should trust on an IdP that is trust certified by the central bank. 4. If the trust negotiation is successful, then SPx will join the CoT of matched IdP in the ISE’s FIM region. Otherwise, the client will be rejected for its request as trust negotiation with untrusted SP is failed. 5. After the usual 2FA and Refresh Token/Access Token expiry checking, ISE gets the valid Access Token of matched IdP (whose policies are accepted by SPx while making trust relationship as in Step 3) and passes the encrypted version of the access token to ISE Agent as Transaction Token. 6. ISE Agent appends required additional parameters such as LOA, IdP Id and Digital Signature of ISE along with transaction token with the client’s request and forwards it to SPx by establishing a dedicated broker connection. 7. SPx verifies the digital signature of ISE, as communicated during trust negotiation, to confirm the request is coming from a valid source. 8. SPx communicates with IdP (which is extracted from the request) for transaction token validation. 9. IdP gets the ISE’s service to acquire the encrypted value of its generated Access Token and matches against with the received transaction token. If both matches, then IdP signals SPx to provide service to the client or deny the service otherwise. 10. The established broker thread will be closed at the end of service by ISE Agent. Upon expiry of agreed-on trust duration, the attached untrusted SP will be detached automatically with CoT. The implementation of the proposed security architecture and cross-sectional analysis of its capability with existing FIM solutions is required to validate the improvement of the overall security in FIM. Next section describes the implementation and validation of the proposed security architecture.

4. Proposed security architecture validation The proposed security solution is implemented and tested with large-scale financial data in a real-time SOA environment that implements both RESTful and SOAP Web services. The Hardware and Software configuration that is used for this Proof-of-Concept (PoC) is as stated in Table 3.

9

Table 3 SOA Testing Environment for PoC. Hardware/Software

Configuration/Capacity

Processor Total Main Memory Operating System Application Server Web Services

Intel(R) Xeon(R) @ 2.30 GHz; 16 CPUs; 64 bit 32 GB; Secondary Storage: 500 GB Red Hat Linux 4.8 IBM WebSphere 7 JAX-RS for REST; JAX-WS for SOAP-based; Developed using Spring Framework (Java) and Restlet Framework Asymmetric Keys: RSA; Symmetric Key: Blowfish Hash Function: MD5; XKMS: Open XKMS

Crypto Algorithms

The interpretation of obtained results shows that the proposed architecture improves the security comprehensively for SSO based FIM solutions when compared to the existing FIM solutions such as SAML, OAuth and OpenID. Proposed architecture extends federated identity to inter-organizational level without forcing the clients to have multiple authentication accounts with interconnected IdPs and dynamic trust on service providers from other regions. Achieving these capabilities is a novel and significant contribution of this research. As mentioned earlier, these capabilities are very difficult to be achieved in existing federated identity management systems without compromising security concerns. Most importantly, the proposed architectural solution does not breach any security and identity federation standards and specifications of the industry. The reason is that it adapts to the existing solutions and enhanced them where needed. The additional execution time or operational latency of the proposed security solution is very minimal. It can be observed within the SLA of any securitycentric federated identity enterprise computing services. 4.1. Proposed adaptive security algorithm The algorithm is devised based on the usage of proposed security architecture to fulfill the desired objective of providing SSO based identity federation without compromising security. For easier understanding of the proposed algorithm, only access tokens are used to be encrypted. However, the security engine in ISE is fully equipped with PKI so that each and every requests/responses with clients/SPs can be secured with public key cryptographic techniques as needed by the computing environment. The proposed algorithm is shown in Fig. 7 with simplified steps. 4.2. Implementation and results Considering the length of this paper, we briefly discussed here on how our proposed adaptive security architectural model protects identity federation defending against potential attacks and fulfills the existing security gaps with the existing available solutions. ISE is private to underlying organizational environment, it is equipped with load-balancing & high availability capabilities, and keeps the identity details accurate by updating with its database periodically. Thus, ISE fulfills the three important information security demands: Confidentiality, Availability, and Integrity. With this high availability feature, the proposed solution will not be resulted in single point of failure as requested service will be routed to other available IdPs through linkage service option even if a particular IdP fails to serve. This high availability feature cannot be expected in individual IdPs of SOA as it will demand additional infrastructure and software licenses. ISE enforces 2 Factor Authentication so that the underlying FIM is not totally dependent on IdP’s authentication mechanism.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

10

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

requests for detecting potential attacks such as replay, DoS, session-based, token-based, code based, parsing based and network-based attacks through its inbuilt security engine, which is equipped with security algorithms written by the same authors on Prevent-Protect-Learn cyclic model as presented in their previous papers (Ibrahim and Hassan, 2016; Beer and Hassan, 2017; Ibrahim and Hassan, 2015). These novel security algorithms are developed specifically to construct the core part of ISE. A result of the test run on Proof-of-Concept (PoC) with defaulted network layer security, vendor security, and proposed security solutions is depicted in Fig. 8. Different vendor solutions are chosen for PoC for each type of security attacks as there is no single and comprehensive vendor security solution that addresses all the security vulnerabilities at present, as stated in problem statement at section 2. The results in the graph can be interpreted as straightforward as 1 that represents no security (attacks are very high) and 0 that represents high security (protection is high). The interpretation of results clearly shows that the proposed security solution outperforms the defaulted OSI network/transport layer security and vendor security solutions. This is acquired by keeping the fact that achieving 100% security is more challengeable without compromising to the standards/specifications of SOA and related technologies, and without breaching the SLA timeline and without additional hardware/software cost. Proposed security solution provides better results without violating industrial standards. Moreover, software-based solutions are cheaper than hardware-based security solutions in the widespread of large-scale enterprises. As ISE intermediates on the request/response flow, additional clock synchronization between clients and servers is not required. This feature enriches the performance of federated identity by eliminating additional heartbeat calls between client and servers, and it also avoids the overhead cost of having additional infrastructure. The salient features of the proposed security solution in comparison to the behavior of existing security solutions are tabulated in Table 4. As the proposed security solution checks message correlation identifiers with persistent data of message headers to prevent replay attacks, additional clock synchronization is not required. The proposed security solution is fully software based and it will run on the existing minimum hardware that does not require any additional hardware components such as special routers unlike some vendor security products demand for. As the PoC is performed using Java and related technologies, the solution can claim itself as platform independent that can be deployed at any platform and any machine architecture that supports SOA implementation. Moreover, the solution is presented as an architectural

Fig. 7. Algorithm for the proposed solution (in simplified steps).

Requests for SPs are interpreted first by ISE for security screening before forwarding them to actual SPs. ISE will screen the

Fig. 8. Proposed security solution outperforms over network layer security and vendor security.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Table 4 Requirement of supporting technologies in existing and proposed security solutions. Technologies/Supporting Infrastructure

Existing Solution(s)

Proposed Solution

Clock Synchronization between client and servers Additional Hardware

Required

Platform dependency

Restricted

Option to choose authentication methods Single Point of Failure Elevation of access privileges by intruders Service availability at cross-organizational level with single time sign on Identity theft and interpretation Platform trustworthiness with IdPs and SPs Security protocols and Secure transactions Phishing/Eavesdropping Scalability of computing nodes

Few High High Moderate

Not Required Not Required Not Required Many Low Low High

Inter-organizational FIM

Restricted

Comprehensive security for FIM Security code implementation/configuration 2 Factor Authentication (2FA)

Restricted Complex Not Supported Not Supported

Dynamic Trust of SPs within CoT

Required

Moderate Moderate Moderate High Restricted

Very Low High High Low No constraint No constraint High Simple Supported Supported

model, not as a product. Hence, the proposed solution can be rewritten in any modern programming languages. Many vendor products do not provide options to the users to choose the authentication methods as they are restricted to their product implementation, but the users can select any authentication methods of their choice in our proposed security model (George et al., 2017; Roopa, 2015; Chadwick and Inman, 2013). Additional encryption layer in our proposed security framework provides extra security for identity data, hence identity theft and interpretation became low as observed by PoC result. Dynamic trust of service providers with CoT and tailorable security configurations are the additional features which are newly introduced in our proposed security solution. For measurement purpose, below 10% range is marked as Very Low, below 25% to 10% range is marked as Low, below 50% to 25% range is marked as Medium and 50% and above range is marked as High. As security is hardened using asymmetric key cryptography and hashing techniques/digital signatures, identity theft attacks have become very difficult to succeed. Even if an attacker succeeds in obtaining a transaction token by snipping the network packets, he/she cannot get any benefit out of that token as it will be in an encrypted format and only the concerned IdP can validate it with the help of ISE. For example, the transaction token of access token value ‘‘ABC” is ‘‘902fbdd2b1df0c4f70b4a5d23525e932” which is invalid when used as an access token. The attacker cannot be succeeded in getting access to SP even if he/she uses this snipped value as transaction token because hashing functionality is fully handled by ISE and provided only to authenticated clients with legitimate IdPs. The security vulnerabilities with OpenID are highly addressed with ISE as it uses strong PKI protocols and 2FA. If a user’s session with ISE became expired, then no way the user can access any SP as all access tokens/refresh tokens are maintained at ISE, not at the client level. The trust negotiation between untrusted SP and IdP in ISE’s CoT is based on strong policy assertions including credential validations, so that it is not easy for an intruder to impersonate as a valid SP to join with CoT. In the conducted PoC, an SP of Bank_B wants to join in CoT of Bank_A as trusted SP so that any client application in Bank_A can directly access the services at that SP in Bank_B through FIM. For this case, the trust negotiation is per-

11

formed between ISE at Bank_A and SP at Bank_B with defined security policies that include, (i) Both Bank_A and Bank_B must be certified by central bank, (ii) the concerned SP of Bank_B should have trust relationship with any one of the IdPs in Bank_B which should be in turn authenticated by central bank and (iii) the IdP in Bank_B where the concerned SP has trust relationship should provide authentication service to ISE in Bank_A. Asserting these strong security policies makes it very difficult for an attacker to include any vulnerable SP in a CoT of ISE. 4.3. Analysis and discussion Nowadays, security on federated identity management has become an interesting and active research area in enterprise computing. In this section, the existing and related solutions are reviewed briefly in comparison with the proposed solution. There are few papers (Singh et al., 2016; Sha et al., 2010; Khan, 2016) in the literature which analyzed the security limitations of single sign-on and identity management. Naik and Jenkins (Naik and Jenkins, 2017) addressed in detail on securing digital identities in the cloud by selecting appropriate federated identity management solution. However, their findings are not sufficiently focused on security issues with federated identity management at a crossorganizational level which is mandatory at this age of serviceoriented computing. Few research works (George et al., 2017; Roopa, 2015; Shrishak et al., 2016) are conducted with the aim of enhancing security for federated identity using policy attributes and encryptions. Shrishak et al. (Shrishak et al., 2016) presented a method on how user’s attributes can be stored at IdP level in a privacy-friendly way without using usual unique identifiers. Even though the authors proposed to use multiple databases for persisting privacy attribute data, it will not be an effective method when the data scales. Moreover, persisting privacy data at multiple locations will lead to additional vulnerabilities. There are three research works (Chadwick and Inman, 2013; Barreto et al., 2015; Gao et al., 2010) that are closer to our proposed solution, but they lack in fulfilling mandatory security requirements to result in a comprehensive solution. Also, they work on weaker security concepts such as policy assertions and linking particularly when accessing services at SPs under different IdPs, which may result in additional security vulnerabilities. Our aim is to present a compressive security architectural model for federated identity management at the cross-organizational level without breaching the existing security standards and specifications defined for service oriented architecture in an adaptive way forward. So that we enhanced the federated identity architecture with IdP linkage feature for inter-organizational service connectivity and dynamic trust enablement on untrusted SPs along with PKI based security enforcement that works on intelligent based security mechanism. With the introduced features of secured federated identity management at the inter-organizational level, trust negotiation process for including an untrusted service provider in the circuit of trust and Predict-Prevent-Learn pattern for defending against security attacks, the proposed model is novel and comprehensive for securing and managing identity federation for the enterprise computing environment. Moreover, the proposed solution is software-based which reduces the unnecessary need of having special hardware as some vendor products demand for, thus the proposed solution is a better choice of implementing identity federation. 5. Conclusion In this modern era of enterprise application integration, almost all business functionalities are exposed and shared as services. It is

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

12

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx

all due to two important reasons: flexibility on loosely coupled application components and ease of use; especially accessing all the privileged services which are provided by multiple service providers with single time authentication. This single time authentication that is implemented using federated identity constructs provides not only ease of access to the users but also considered as mandatory at this age of complex network architectures. At the same time, security is raised as a major concern with this single time authentication in SOA. On the other side, most of the existing identity federation systems are restricted to support with only one identity provider per service session due to the difficulties of managing identities and keeping the trust between the underlying entities. The existing federated identity management mechanisms such as SAML, OAuth and OpenID excessively rely on Circuit of Trust (CoT), but a cross-domain single sign on (SSO) is needed for implementing federated identity at the inter-organizational level crossing the borders of tight CoT. Expanding the borders of CoT for federated identity management is challengeable and it may introduce additional security vulnerabilities. In this paper, the security gaps of existing federated identity management solutions and the need for having a federated identity at the inter-organizational level are analyzed first. As part of our previous research, we constructed a security component named Intelligent Security Engine (ISE) that works based on PredictPrevent-Learn pattern for defending against security attacks on service oriented architecture. Based on this ISE’s principle, we presented a comprehensive security architectural model with a proofof-concept for protecting federated identity management by an adaptive way forward solution that works for simple and interorganizational service oriented application integration.

6. Future work The next generation of Service Oriented Architecture (SOA) is Software as a service (SaaS) initiative. It is a way forward solution for accessing centrally hosted Software applications over the web as services. It enriches the core features of SOA, the flexibility of loose coupling and reduced costing, as it frees the consumers from software/hardware installation and management. In SaaS, the entire application is shared as a service to its customers as superior to SOA that shares only the particular business functionalities as services. Again the security is the major concern with SaaS. Gartner Inc., a leading research and advisory organization on IT security, forecasts that worldwide enterprise security spending is to be a total of 96.3 billion USD in 2018, an increase of 8% from 2017 (Garter Forecast, 2018). Therefore, the proposed security architecture should be enhanced periodically to cater for the latest initiatives of service orchestration, as required. The future work on this research topic includes, (i) construct Identity as a Service (IDaaS) architectural model instead of identity management as an API, (ii) enforcing Zero Trust model on FIM that there will be no Circuit of Trust (CoT) and all elements in FIM including IdPs should be treated as on the same security level for authentication, (iii) Expanding the security features of ISE for Identity Governance and Administration (IGA) model, where IGA is the latest trend in centralized orchestration of user identity management and access control. References Beer, M.I., Hassan, M.F., 2017. Adaptive security architecture for protecting RESTful web services in enterprise computing environment. Service Oriented Computing and Applications, 111–121. Saadeh, Maha, Sleit, Azzam, Qatawneh, Mohammed, Almobaideen, Wesam, 2016. Authentication techniques for the internet of things: a survey. In: IEEE Cybersecurity and Cyberforensics Conference (CCC), pp. 28–34.

Ling, Chung-Huei, Lee, Cheng-Chi, Yang, Chou Chen, Hwang, Min-Shiang, 2017. A secure and efficient one-time password authentication scheme for WSN. Int. J. Network Security 19 (2), 177–181. Mainka, C., Mladenov, V., Schwenk, J., 2016. Do not trust me: using malicious IdPs for analyzing and attacking Single Sign-On. In: IEEE European Symposium on Security and Privacy, pp. 321–336. Masood, Adnan, Java, Jim, 2015. Static analysis for web service security – Tools & techniques for a secure development life cycle. In: IEEE International Symposium on Technologies for Homeland Security, pp. 1–6. Yarygina, Tetiana, Bagge, Anya Helene, 2018. Overcoming security challenges in microservice architectures. In: IEEE Symposium on Service-Oriented System Engineering, pp. 11–20. SAML Specifications. http://saml.xml.org/saml-specifications Accessed 15 Apr 2018. The OAuth 2.0 Authorization Framework. https://oauth.net/2/ Accessed 15 Apr 2018. OpenID Authentication 2.0 Specification. https://openid.net/specs/openidauthentication-2_0.html Accessed 15 Apr 2018. Malik, Ali Ahmad, Anwar, Hirra, Shibli, Muhammad Awais, 2015. Federated identity management (FIM): Challenges and opportunities. In: IEEE Conference on Information Assurance and Cyber Security, pp. 75–82. Chen, Ju, Liu, Yi, Chai, Yueting, 2015. An identity management framework for internet of things. In: IEEE International Conference on e-Business Engineering, pp. 360–364. Ouaddah, Aafaf, Mousannif, Hajar, Elkalam, Anas Abou, Ouahman, Abdellah Ait, 2017. Access control in the internet of things: big challenges and new opportunities. Elsevier Comp. Netw. 112, 237–262. Sharma, Deepak H., Dhote, C.A., Potey, Manish M., 2016. Identity and access management as security-as-a-service from clouds. Elsevier Proc. Comput. Sci. 79, 170–174. OWASP Top 10 Application Security Risks – 2017. https://www.owasp.org/index. php/Top_10-2017_Top_10 Accessed 6 Jan 2019. Islam, T., Manivannan, D., Zeadally, S., 2016. A classification and characterization of security threats in cloud computing. Int. J. Next-Gen. Comput. 7 (1), 1–17. Simpson, S., Groß, T., 2016. A survey of security analysis in federated identity management. In: Privacy and Identity Management: Facing up to Next Steps, IFIP Advances in Information and Communication Technology. Springer, pp. 231–247. Almorsy, M., Grundy, J., Müller, I., 2016. An analysis of the cloud computing security problem. Proceedings of Asia-Pacific Software Engineering Conference (APSEC) Cloud Workshop, arXiv preprint. arXiv:1609.01107. Mahmoud, R., Yousuf, T., Aloul, F., Zualkernan, I., 2015. Internet of things (IoT) security: current status, challenges and prospective measures. In: IEEE International Conference on Internet Technology and Secured Transactions, pp. 336–341. Ibrahim, B.M., Hassan, M.F., 2015. A new customizable security framework for preventing WSDL attacks. In: IEEE International Conference on Research Challenges in Information Science, 24–29. Ibrahim, B.M., Hassan, M.F., 2016. Construction of customizable SOA security framework using artificial neural networks. Jurnal Teknologi, 69–75. Kumar, Arvind, 2016. Applying separation of concern for developing softwares using aspect oriented programming concepts. Elsevier Proc. Comput. Sci. 85, 906–914. Jain, Manish, Gopalani, Dinesh, 2016. Testing application security with aspects. In: Proceedings of IEEE International Conference on Electrical, Electronics, and Optimization Techniques (ICEEOT), pp. 3161–3165. Burr, William E., Dodson, Donna F., Polk, William T., 2004. Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology Technical Report 800–63. National Institute of Standards and Technology (NIST). Ferdous, M.S., Norman, G., Jøsang, A., Poet, R., 2015. Mathematical modelling of trust issues in federated identity management. In: IFIP International Conference on Trust Management. Springer, pp. 13–29. MI Beer, MF Hassan, Adaptive security architecture for protecting RESTful web services in enterprise computing environment, In: Springer journal of Service Oriented Computing and Applications, 2017, 111-121. BM Ibrahim and MF Hassan, A new customizable security framework for preventing WSDL attacks, In: IEEE International Conference on Research Challenges in Information Science, 2015, 24-29. George, J.A., Veni, S., Soomroo, S., 2017. Improving privacy and trust in federated identity using SAML with hash based encryption algorithm. In: IEEE International Conference on Engineering Technologies and Applied Sciences, pp. 1–5. Roopa, S.R., 2015. SSO-key distribution center based implementation using serpent encryption algorithm for distributed network (securing SSO in distributed network). In: IEEE International Conference on Advanced Computing, pp. 425– 429. Chadwick, D.W., Inman, G., 2013. The Trusted Attribute Aggregation Service (TAAS) – providing an attribute aggregation layer for federated identity management. In: IEEE International Conference on Availability, Reliability and Security, pp. 285–290. Singh, Saurabh, Jeong, Young-Sik, Park, Jong Hyuk, 2016. A survey on cloud computing security: issues, threats, and solutions. J. Netw. Comput. Appl. 75, 200–222. Sha, S., Qiao Yan, W., Zhu Li, M., 2010. A secure SSO protocol without clock synchronization. IEEE Int. Conf. Adv. Comput. Theory Eng. 3, 422–424. Khan, Minhaj Ahmad, 2016. A survey of security issues for cloud computing. J. Netw. Comput. Appl. 71, 11–29.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004

M.I. Beer Mohamed et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Naik, N., Jenkins, P., 2017. Securing digital identities in the cloud by selecting an opposite Federated Identity Management from SAML, OAuth and OpenID Connect. In: IEEE International Conference on Research Challenges in Information Science, pp. 163–174. Shrishak, K., Erkin, Z., Schaar, R., 2016. Enhancing user privacy in federated eID schemes. In: IEEE International Conference on New Technologies, Mobility and Security, pp. 1–5.

13

Barreto, L., Fraga, J., Siqueira, F., 2015. Architectural model and security mechanisms for cloud federations. IEEE Trustcom/BigDataSE/ISPA 1, 1108–1115. Gao, H., Yan, J., Mu, Y., 2010. Dynamic trust model for federated identity management. In: IEEE International Conference on Network and System Security, pp. 55–61. Gartner Forecast: Information Security, Worldwide, 2015-2021, 3Q17 Update. https://www.gartner.com/newsroom/id/3836563 Accessed 15 Apr 2018.

Please cite this article as: M. I. Beer Mohamed, M. F. Hassan, S. Safdar et al., Adaptive security architectural model for protecting identity federation in service oriented computing, Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2019.03.004