Enterprise Security with Identity Access Management

Security Assertion Markup Language (SAML) is the most mature, detailed, and widely adopted specifications family for browser-based federated sign-on for enterprise application users. Once the user authenticates to the identity service, he can freely access provisioned application services that fall within the trusted domain.

Figure 1 illustrates an SSO into Google Apps from the browser. The figure illustrates the following steps involved in the SSO process of a user who is federated to Google:

1) The user attempts to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.

2) Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner's SSO service.

3) Google sends a redirect to the user's browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner's SSO service.

4) The partner decodes the SAML request and extracts the URL for both Google's ACS (Assertion Consumer Service) and the user's destination URL. The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.

5) The partner generates a SAML response that contains the authenticated user's username. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner's public and private DSA/RSA keys.

6) The partner encodes the SAML response and returns that information to the user's browser. The partner provides a mechanism so that the browser can forward that information to Google's ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to Google. The partner could also include JavaScript on the page that automatically submits the form to Google.

7) Google's ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the user to the destination URL.

8) The user has been redirected to the destination URL and is logged in to Google Apps.

Please refer to the static demo (http://ld2.in/15p) of the Security Assertion Markup Language (SAML)-based Single Sign-On Service for Google Hosted Services. The demo is labeled step-by-step to illustrate each step of the SAML workflow between Google and the Partner.

Service Provisioning Markup Language

SPML is an XML-based request response protocol that is used to integrate and interoperate service provisioning requests. The use of SPML is to enable organizations to set up interfaces for web services and applications quickly and securely. This is done by letting portals, application servers, and service centers generate provisioning requests in and across organizations. If you take a typical SOA security stack, SPML satisfies a complementary requirement for authentication, authorization and fine-grained access control. SPML is used for service provisioning whereas the authentication and authorization of data is done through SAML. Fine-grained XML access control is done through XACML.

Nowadays user credentials play a prominent role, be it a network-oriented system or a specific application. Managing user identity is challenging in today's environment given the increasing diversity and complexity of systems. Identity management refers to the management of the entire life cycle of one or more identities, from creation to destruction, and managing privileges.

SPML deals with provisioning these identities in enterprise ecosystems. It brings standardization in preparing system infrastructure to accomplish business activities. A typical SPML use case scenario in organizations is the situation of hiring a new employee, which involves lots of procedures that can be included in a provisioning workflow. Provisioning involves both digital as well as physical activities. A physical activity involves procuring a PC or laptop and a digital activity involves creating a user account in various applications.

Figure 2 illustrates an SPML use case in which an HR system is requesting a provisioning system in the enterprise with the SPML request. In the figure, HR System of Record (requesting authority) is a SPML web services client interacting with the SPML provisioning service provider, which is responsible for provisioning user accounts for enterprise services (provisioning service target).

eXensible Access Control Markup Language

XACML is an OASIS-ratified, general-purpose, XML-based access control language for policy management and access decisions. It provides an XML schema for a general policy language which is used to protect any kind of resource and make access decisions over these resources. The XACML standard not only gives the model of the policy language, but also proposes a processing environment model to manage the policies and to conclude the access decisions. The XACML context also specifies the request/response protocol that the application environment can use to communicate with the decision point. The response to an access request is also specified using XML.

Most applications (web or otherwise) have a built-in authorization module that grants or denies access to certain application functions or resources based on entitlements assigned to the user. In a centrally managed IAM architecture, application-specific authorization models (silos) make it difficult to state the access rights of individual users across all applications. Hence, the goal of XACML is to provide a standardized language, a method of access control, and policy enforcement across all applications that implement a common authorization standard. These authorization decisions are based on various authorization policies and rules centered on the user role and job function. In short, XACML allows for unified authorization policies (i.e., the use of one consistent XACML policy for multiple services).

Figure 3 illustrates the interaction among various health care participants with unique roles (authorization privileges) accessing sensitive patient records stored in a health care application.

Open Authentication (OAuth)

OAuth is an emerging authentication standard that allows consumers to share their private resources (e.g., photos, videos, contact lists, bank accounts) stored on one application service provider with another application service provider without having to disclose the authentication information (e.g., username and password). OAuth is an open protocol and it was created with the goal of enabling authorization via a secure API, a simple and standard method for desktop, mobile, and web applications. For application developers, OAuth is a method for publishing and interacting with protected data. For CSPs, OAuth provides a way for users to access their data hosted by another provider while protecting their account credentials.

Within an enterprise, OAuth may play a role in enabling SSO with a trusted service provider by employing a web services SSO model. OAuth facilitates authorization of a pair of services to interact without requiring an explicit federation architecture. Much like OpenID, OAuth started in the consumer-centric world to help consumer services access customer data hosted across providers. Recently, Google released a hybrid version of an OpenID and OAuth protocol that combines the authorization and authentication flow in fewer steps to enhance usability. Google's GData API recently announced support for OAuth. (GData also supports SAML for browser SSO.)

Figure 4 illustrates the sequence of interactions between customer or partner web application, Google services, and end user:

1) Customer web application contacts the Google Authorization service, asking for a request token for one or more Google service.

2) Google verifies that the web application is registered and responds with an unauthorized request token.

3) The web application directs the end user to a Google authorization page, referencing the request token.

4) On the Google authorization page, the user is prompted to log into his account (for verification) and then either grant or deny limited access to his Google service data by the web application.

5) The user decides whether to grant or deny access to the web application. If the user denies access, he is directed to a Google page and not back to the web application.

6) If the user grants access, the authorization service redirects him back to a page designated with the web application that was registered with Google. The redirect includes the now-authorized request token.

7) The web application sends a request to the Google Authorization service to exchange the authorized request token for an access token.

8) Google verifies the request and returns a valid access token.

9) The web application sends a request to the Google service in question. The request is signed and includes the access token.

10) If the Google service recognizes the token, it supplies the requested data.

Please refer to the sample demo (http://ld2.in/15q) which uses the Google Data Java client to authorize using OAuth. Applications can also delegate authentication to an identity management-as-a-service (IDaaS) provider such as Ping Identity, TriCipher's Myonelogin.com, or Symplified.com.

Conclusion

Customers considering enterprise services (IaaS, PaaS, or SaaS) should consider their organization's operational, security, privacy, and compliance requirements. Enterprise applications must support IAM practices (e.g., federation) and standards (e.g., SAML, OAuth). Applications must automatically provision and manage the user identity life cycle. To save costly integration and avoid retrofitting of features, enterprises should prepare with an IAM strategy and architecture. This will allow enterprises to extend their IAM practice using standard protocols to manage user account provisioning, authentication, and authorization.