Today's identity and access management is not just essential to workplace efficiency—it's also a key factor in reducing Information Technology enterprise costs and delivering value beyond security and compliance services. This is how the market analysts perceive the Identity and Access Management (IAM) market segment today.
Before going further on the IAM arena, let us see what Identity and Access Management is and why organizations should even bother about it. With the advent of information technology, businesses are gearing up to embrace the new technologies in the market to simplify their resource management tasks. Adoption of these technologies improves the productivity in addition to meeting the governmental agencies' compliance requirements. In the olden days it used to be fairly easy to know whom we were dealing with and what they represented; a handshake, a signature, a photograph in a passport, or an identity badge, all played a role in physical identification. In the modern world, where computers and technology play a key role, one needs the electronic equivalents of these, to know whom we are dealing with and what authority they possess.
In an enterprise environment, there is a wealth of information pertaining to the employees, customers, and partners that needs to be stored and managed securely. It is essential to ascertain who can access what kind of information. An identity of an entity can be established by enforcing appropriate authentication systems. This will ensure that the information is accessible only to legally permitted people or entities such as computers, or other network devices such as mobile phones among others. Well, this will guarantee there is no anonymous access to the information available in the company.
However, once authenticated, what information is available to the authenticated identity? Everything, or only selected information that is stored in the corporate database? This is where the access management comes into play. The access management establishes the privileges for the authenticated identity on what kind of information they are authorized to access. For example, an engineering manager does not need to know the company's financial data. This kind of information authorization is provided by the access management systems. In essence, the identity management deals with identity provisioning and synchronization, along with some level of auditing capabilities, whereas as the access management deals with the authentication and authorization information for those entities and what they can do. Together it is called IAM. Implementing proper IAM solutions helps the corporates to manage their information security, and helps to improve business processes and information sharing. For instance, using the federation feature, a business can easily integrate with another partner without replicating any identity information to the partner site, or they can securely exchange attributes of identities without actually storing them at the partner site. It is very critical for businesses to control the access of information and track the accesses to establish accountability on the actions made by the identities on these information resources. This enables the organizations to go back and audit the events in case of any discrepancy or wrongdoing, to track down the culprit.
There have been a lot of incidents in the past where people have stolen information which they were not authorized to access because of no or poor IAM implementation. One of the most notorious examples of the potential harm that can result without identity management is the February 2001 incident where the FBI arrested one of its own veteran counterintelligence agents, Robert Philip Hanssen. He gave more than 6,000 pages of documents containing classified information to Russia and the former Soviet Union. He downloaded most of it from the bureau's computers. Controlling access to certain files makes it more difficult for insiders such as Hanssen, or outside hackers, to steal sensitive information.. Please refer to the following website to know more about the role of IAM in the working of the government.
http://www.nextgov.com/the_basics/tb_20080327_1273.php:
In this chapter we'll discuss the following topics:
- History of OpenSSO
- OpenSSO vs. OpenAM
- OpenSSO—an overview
- What kind of problems does OpenSSO solve?
Back in early 2000, Sun Microsystems Inc. started the Directory Server Access Management Edition project to develop a product that would solve the web Single Sign-On (SSO) problems. The initial scope was to just provide authentication and authorization as part of the SSO using a proprietary protocol. Over the years it evolved to become a lightweight pure Java application providing a comprehensive set of security features to protect the enterprise resources. After undergoing a lot of changes in terms of product name, features, among other things, it ended up with OpenSSO. As part of Sun Microsystems software business strategy, they have open sourced most of their commercial enterprise software products including Sun Java Enterprise System (JES), Java SDK, and Communication suite of products. OpenSSO is the term coined by the Sun's access management product team as part of their strategy to open source Sun Java System Access Manager, Sun Java System SAML v2 Plugin for Federation Services, and Sun Java System Federation Manager. OpenSSO is an integrated product that includes the features of both Access and Federation manager products. The goal was to amalgamate the access, federation, and web services features. This goal was achieved when Sun released the OpenSSO Enterprise 8.0 that received strong market traction and analysts coverage. Sun's OpenSSO product made it to the leadership quadrant in 2008 in the Access Management category which was published by the Gartner Analyst group.
As part of the open source initiative, a lot of code re-factoring and feature alignments occurred that changed the product's outlook. It removed all the native dependencies that were required to build and deploy earlier. OpenSSO became the pure Java web application that enabled the customers and open source community to take advantage of the automatic deployment by just dropping the web archive on any Java servlet container to deploy it. The build and check-in processes were highly simplified which attracted the open source community to contribute to the code and quality of the product.
OpenSSO had a very flexible release model wherein new features or bug fixes could easily be implemented in the customer environment by picking up the nightly, express, or enterprise build. You can find more information on these different builds in the next chapter. OpenSSO Enterprise 8.0 was a major release by Sun that was built from the open source branch. After this release, there were two other express releases. Those were very feature-rich and introduced Secure Token Service (STS) and OAuth functionality. Express build 9 was not released in the binary form by Oracle but the source code has been made available to the open source community. This book is largely based on the binary built from the express build 9 cvs branch. You can download the OpenAM express build, built using the express build 9 branch from the Forgerock site.
As part of the acquisition of Sun Microsystems Inc. by Oracle Corporation that happened back in early 2010, the release and support models have been changed for OpenSSO. If you are interested in obtaining a support contract for the enterprise version of the product, you should call up the Oracle support team or the product management team. Oracle continues its support for the OpenSSO enterprise's existing customers. For the OpenSSO open source version (also known as OpenAM) you can approach the Forgerock team to obtain support.
OpenSSO was the only open source product in the access management segment that had production level quality. Over eight thousands test cases were executed on twelve different Java servlet containers. OpenSSO is supported by a vibrant community that includes engineers, architects, and solution developers. If you have any questions, just send a mail to< [email protected]>, and you are likely get the answer to what you want to know.
Recently Forgerock (http://www.forgerock.com) undertook an initiative to keep the community and product strong. They periodically fix the bugs in the open source branch. Their version of OpenSSO is called OpenAM, but the code base is the same as OpenSSO. Pretty much all of the examples and code cited in this book should work with the OpenAM as well. Nevertheless, there may be incompatibilities in future if OpenAM code base deviates a lot from the OpenSSO express build 9 code base. Note that the Oracle Open SSO Enterprise 8.0 update releases are based on the OpenSSO Enterprise release 8.0 code base, whereas the open source version OpenAM is continuing its development from the express build 9 code base. Throughout this book OpenSSO references can be interpreted as OpenAM as well with respect to the OpenSSO build 9 branch.
OpenSSO is a freely available feature-rich access management product; it can be downloaded from http://www.forgerock.com/openam.html. It integrates authentication and authorization services, SSO, and open standards-based federation protocols to provide SSO among disparate business domains, entitlement services, and web services security. Overall, customers will be able to build a comprehensive solution for protecting their network resources by preventing unauthorized access to web services, applications, web content, and securing identity data.
OpenSSO offers a complete solution for securing both web applications and web services. You can enforce a comprehensive security policy for web applications and services across the enterprise, rather than relying on developers to come up with ad hoc ways to secure services as they develop them. OpenSSO is a pure Java application that makes it easy to deploy on any operating system platform or container as it supports a broad range of operating systems and servlet containers.
In this book, all of the features are not covered as the scope of the book does not permit to discuss all of them. Nevertheless, some of the core use cases are captured very well. For example, a separate chapter is devoted to discussing integrating the SaaS-based applications with OpenSSO infrastructure.
All the services provided by the OpenSSO are exposed over HTTP protocol. The clients access them using appropriate interfaces. OpenSSO exposes a rich library of Application Programming Interfaces (APIs) and Service Provider Interfaces (SPIs) using which, customers can achieve the desired functionality. These services developed for OpenSSO generally contain both a server component and a client component. The server component is a simple Java servlet developed to receive XML requests and return XML responses. The opensso.war web application (about to be introduced in the next chapter) encompasses all the services and associated configuration items that are required to deliver the OpenSSO functionality. The client component is provided as Java API, and in some cases, C API. This allows remote applications and other OpenSSO services to communicate with and consume the particular functionality.
Each core service uses its own framework to retrieve customer and service data and to provide it to other OpenSSO services. The OpenSSO framework integrates all of these service frameworks to form a layer that is accessible to all product components and plugins as shown in the following diagram:
Most of the core services are discussed in the forthcoming chapters. There are certain services that are not covered due to the scope of this book. Just to make you aware of the breadth of features provided by the OpenSSO, in the next few sections, some of the prominent features that are not covered in this book will be briefly introduced.
Typically, in the web access management the Single Sign-On happens in the same company, within the same Domain Name Service (DNS) domain. Most of the time this will work for small companies or in B2C type scenarios, whereas in a B2B scenario use of a DNS domain-based SSO will not work as the cookie will not be forwarded to the other DNS domains. Besides, there are privacy and security concerns to perform SSO across multiple businesses using this approach. So how do we solve these kinds of problems where customers want to seamlessly sign on to services even though the services are provided by a third party?
Federation is the solution. So, what is federation? Federation is a process that establishes a standards-based method for sharing and managing identity data and establishing a Single Sign-On across security domains and organizations. It allows an organization to offer a variety of external services to trusted business partners, as well as corporate services to internal departments and divisions. Forming trust relationships across security domains allows an organization to integrate applications offered by different departments or divisions within the enterprise, as well as engage in relationships with co-operating business partners that offer complementary services. Towards the federation or solving SSO across multiple domains, multiple industry standards, such as those developed by the Organization for the Advancement of Structured Information Standards (http://www.oasis-open.org) (OASIS) and the Liberty Alliance Project (http://www.projectliberty.org/), are supported. OpenSSO provides an open and extensible framework for identity federation and associated web services that resolves the problems of identity-enabling web services, web service discovery and invocation, security, and privacy. Federation services are built on the following standards:
- Liberty Alliance Project Identity Federation Framework (Liberty ID-FF) 1.1 and 1.2
- OASIS Security Assertion Markup Language (SAML) 1.0 and 1.1
- OASIS Security Assertion Markup Language (SAML) 2.0
- WS-Federation (Passive Requestor Profile)
SAML 2.0 is becoming the de facto standard for the federation SSO as many of the vendors and service providers support SAML 2.0 protocol. For instance Google Apps and Salesforce support SAML 2.0 as their choice of protocol for SSO.
The OpenSSO Web Services Stack follows a standardized way of integrating web-based applications using XML, SOAP, and other open standards over an Internet Protocol (IP) backbone. They enable applications from various sources to communicate with each other because they are not tied to any one operating system or programming language. Businesses use web services to communicate with each other and their respective clients without having to know detailed aspects of each other's IT systems. OpenSSO provides web services that primarily use XML and SOAP over HTTP(s). These web services are designed to be centrally provided in an enterprise's network for convenient access by client applications. OpenSSO implements and exposes about eight services that can be obtained by entering the following URL in your browser http://opensso-server.domain.net:port/<uri>/identityservices, for example, http://opensso.packt-services.net:9090/opensso/identityservices. This URL follows the example that we will be using in later chapters.
Before jumping onto securing web services, let us understand the concept of transport-layer security and message-level security. Transport-level security happens at the channel level.
Transport-level security secures the communication at the channel level. For example, protocols such as TCP, HTTP, MSMQ, and so on have their own security mechanisms to secure their communication channel. SSL/TLS is predominantly used for securing the transport-level security. It is point-to-point security, which means the secure channel is guaranteed only to the end point between the consumer and the server. If the message passes through the intermediaries such as proxy or a load balancer before reaching the destination server then the rest of the communication channel must be secured, but that is something the sender cannot control. Potentially the message can be tampered by the intermediaries.
Unlike the transport-level security, the message-level security is highly reliable as it secures the message itself. This means the message-level security is transparent to the underlying transport protocol. It is handled at the application level itself that is why it is often called application-level security or end-to-end security. This provides more flexibility as the application developer can decide which part of the message is to be signed or encrypted. In a large message it may be that only a smaller portion is required to be secured such as the authenticated identity's attribute.
This message-level security is available as Web Services Security in OpenSSO and through the installation of a web services security agent such as the JSR196 Glassfish agent (http://jcp.org/en/jsr/detail?id=196). Web Services Security is the implementation of the WS-Security specifications and the Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF). Web Services Security allows communication with the STS to insert security tokens in outgoing messages and evaluate incoming messages for the same. Towards this end, authentication agents based on the Java Specification Request (JSR) 196 must be downloaded and installed on the Web Service Client (WSC) machine and the Web Service Provider (WSP) machine.
To secure web services communications, the requesting party must first be authenticated with a security token which is added to the SOAP header of the request. Additionally, the WSC needs to be configured to supply message-level security in their SOAP requests and the WSP needs to be configured to enable message-level security in their SOAP responses.
OpenSSO Entitlements Service is a brand new component introduced in OpenSSO express build 9. It is a fine-grained policy management solution that allows for centralized administration and evaluation of access control rules for enterprise applications and resources. As the entitlement market is maturing, more vendors have started supporting fine-grained policies including Oracle and IBM. OpenSSO Enterprise 8.0 does not have this feature. To fill this gap and catch up with the market, OpenSSO Entitlements Service is introduced in the express build 9.
The IT architects and solution developers have always desired to externalize the authorization processing from business applications for centralized administration and to delegate the security code to security products. In the modern age of Web 3.0 development and deployments, it is increasingly important to adopt an architectural model where authorization and entitlement management are consumed as a service rather than embedded within business applications.
OpenSSO Entitlements Service consists of Policy Policy Administration Point (termed as PAP) and Policy Evaluation Engine or Policy Decision Point (PDP). Additionally, there is Policy Enforcement Points (PEP) that is usually executed within the applications and enforces the policy decisions obtained from PDPs. Together, they provide a unified policy management, delegated policy administration, and distributed policy decision-making and enforcement.
The existing policy management component of OpenSSO, which has a similar architecture as OpenSSO Entitlements Service, has the limitation of having a proprietary policy language. Its performance and scalability are acceptable only for coarse-grained policies and does not lend itself to a Service Oriented Architecture (SOA). The new component Entitlements Service will overhaul the policy management component by adopting eXtensible Access Control Markup Language (XACML) as the policy language. It has the ability to scale up to a million policies, and provide REST/SOAP interfaces for policy management and evaluation. These enhancements will enable architects to externalize fine-grain authorization processing to OpenSSO and will enable developers to quickly develop PEPs for their applications.
OpenSSO Entitlements Service is compatible with the existing policy framework and the current agents will continue to work with entitlements enabled. Both administrative console interfaces and command line interfaces are provided for the policy management. The interface is very intuitive to the administrative user.
You can challenge that not one single product in the Identity and Access Management arena offers the set of features that OpenSSO encompasses within it. It can solve a wide range of problems in the enterprise security domain.
You can deploy OpenSSO to solve the following four kinds of problems (OpenSSO can be used to address the these primary issues associated with balancing risk and reach):
The traditional challenge of internal SSO still exists for many organizations—and it's now compounded by the additional need for extranet authentication. Even if you've found a way to handle the former, the solution involved is not likely to be designed to take care of the latter.
This problem can be solved by deploying the OpenSSO, thereby centralizing the server and agents' configuration as part of the embedded configuration store. The embedded configuration store is based on the highly performing embedded OpenDS. This reduces the cost of procuring another software to hold the configuration data. OpenSSO offers policy agents for all the popular web and application servers by installing the agents. The proxy model can also be leveraged for the SSO solution based on the deployment. Using the distributed authentication components the extranet access can be controlled. Overall the administrative cost can be brought drastically down by deploying the OpenSSO.
Federation provides an opportunity to expand business reach by providing more services through collaboration with partners. At the same time, if the customer wants to federate, he or she should be mindful of the need to secure these resources preferably in a repeatable, scalable way that accommodates growth.
Employing OpenSSO-based solutions enables the customer to leverage the standards-based protocols that are supported including the OASIS Security Assertion Markup Language (SAML) 2.0.
OpenSSO offers a truly lightweight means of federating: The Fedlet, a less than 10 megabytes in size package that identity providers provide to service providers so that they can federate back to a company without the need for any additional federation product. To become federation-enabled, the service provider simply adds the Fedlet to their application and deploys the application. No configuration is required, and it works with both Java and .NET applications. It provides an easy-to-use interface to validate service provider connections on-the-fly. Another feature called virtual federation proxy capability eliminates the need to have an already established SSO across the enterprise before being able to federate legacy authentication applications to service providers.
The multi-protocol feature makes OpenSSO a perfect solution in the federated environment, wherein different providers in the circle of trust use heterogeneous federation protocols. OpenSSO is transparent to these protocols and can achieve SSO by leveraging the multi-protocol feature.
While many companies have invested considerably in centralized authentication and authorization for applications, few have done the same for web services. Now, however, many are recognizing the importance of abstracting web services away from the developer as part of an effort to standardize their security model across the organization.
How can OpenSSO be used to secure web services? IT leverages the message-level security along with the Security Token Service to secure web service requests/responses. It supports only standards-based solutions in the world to provide a pluggable, end-to-end secure web services solution. Web service developers can utilize the Netbeans IDE along with Glassfish to develop and test their web services. This expedites the development cycle as Netbeans inherently provides tools to enable the web service development.
Besides, the embedded Security Token Service can be deployed as an integrated or a standalone solution to handle the security token issuance. As it is standards-based, all the token validation and translations are done via WS-Trust protocol. Customers can use the web services security agents as the policy enforcement point for the popular containers including the JBOSS application server.
The Entitlements Service in the OpenSSO express build 9 replaces the proprietary policy definition and evaluation engine with a more standards-based, highly scalable framework. Nonetheless, the new policy engine will continue to honor the old type of policy requests that are coming from the existing deployments. The motivation behind the new engine is to improve the administration, scalability, and performance.
The new policy engine's performance benchmark will be in millions. The policy definition language will change from the proprietary format to OASIS XACML-based. With this change, one should be able to import and export policies easily from one vendor to another enabling the portability that might expedite the migration process. A new administrator user interface that is based on ICEFaces framework yields a better administration experience.
The following diagram captures the salient features of these four problems and the solution provided by the OpenSSO server:
