Quite often users get confused with the Configuration store and the Identity Store (also called User store or User repository). Let us be clear on this terminology because we will deal with these terms throughout this book. It is critical to know the distinction between these two repositories to better understand the OpenSSO concepts.
Configuration store or Configuration repository is used to store the configuration information of the OpenSSO server. This is the core part of the server that provides crucial information to start up the services provided by OpenSSO. If this store is down, then the OpenSSO server will not even start successfully. This repository contains critical pieces of configuration information, including:
- Host name, port, URIs of the OpenSSO server(s), and services
- List of services supported and their configuration details, such as Authentication and Audit
- Policy information to provide authorization services
- Realms and realm-specific configuration
- Information about the Identity stores configured for the realms
- Information about the servers that provide failover capability to support high availability
- Centralized configuration data of OpenSSO policy agents and Web Service Clients
- Information about administration of OpenSSO
At the time of writing (OpenSSO Express Build 9) OpenSSO supports a built-in embedded configuration store, as well as a highly scalable external Sun Java System Directory Server store.
The embedded store is part of the opensso.war that does not require any pre-configured Sun Java System Directory Server. This embedded store is sufficient for a medium-sized deployment. For larger deployment with high availability and scalability requirements, it may be worth using Sun Java System Directory Server as the configuration data store.
Embedded configuration store is based on the OpenDS which is a pure Java-based LDAPv3 compliant directory server, open source and is available via CDDL license (https://www.opends.org/). Using embedded store is the quickest and easiest way to bring up the OpenSSO server. Besides, it does not involve any cost. However, using Sun Java System Directory Server for storing configuration data requires you to buy the software from the vendor. On the other hand, the Java servlet container's JVM is responsible for running and managing the embedded store, as shown in the following diagram, and this puts extra load on the container subsequently limited by the JVM performance. Throughout this book, all the examples are generated with embedded configuration store unless mentioned otherwise.
Even though the configuration store is based on OpenDS, you cannot manage this using the OpenDS tools that you can download from https://opends.dev.java.net/. The specific version that is embedded is highly customized and fine-tuned for the OpenSSO product. The existence of the OpenDS port is supposed to be treated as black box by the OpenSSO administrators and users. To manage the configuration data, OpenSSO does provide both GUI and command line interfaces.
In the default configuration, the configurator (refer to section Configuring OpenSSO) does create a user identity store that points to the embedded configuration store. This user store is meant to be used to validate the OpenSSO configuration and functionality, such as Single Sign-On (SSO) verification with the SAMLv2 provider. Creating and managing user identities in embedded store at a large scale is not something that is a recommended practice. It is always recommended to use a separate identity store such as OpenDS with OpenSSO.
For most of the deployments, using built-in embedded configuration store would be sufficient and cost effective. Nevertheless, for applications that require high availability and scalability it may be worth considering Sun Java System Directory Server as the configuration store. With this kind of configuration, it is possible to achieve the highest level of availability and scalability that is supported by the OpenSSO product.
Having an external directory offers distinct advantages of keeping the container and configuration store separate, as shown in the following diagram:
This takes the burden off managing the embedded configuration store from the container's Java Virtual Machine. Only the Sun Java Directory Server supports the configuration store. None of the other LDAPv3 compliant servers including an externally configured OpenDS, Microsoft Active Directory, and IBM Tivoli Directory Server are supported. The table in this section outlines the supported directory servers for the OpenSSO configuration and identity store.
|
Store type |
Version |
Configuration store |
Identity store |
|---|---|---|---|
|
Sun Directory Server Enterprise Edition |
5.2, 6.3, and 7.0 |
X |
X |
|
Embedded Store |
2.x |
X |
X |
|
Microsoft Active Directory |
Windows 2003 and Windows 2008 |
Not Supported |
X |
|
Microsoft Active Directory Application Module(ADAM) |
Windows 2003 and Windows 2008 |
Not Supported |
X |
|
IBM Tivoli DS |
6.1 |
Not Supported |
X |
|
Access Manager Respository(amSDK) |
Sun Java System Directory Server 5.2, 6.3, and 7.0 |
Not Supported |
X |
|
Externally Configured OpenDS |
2.x |
Not Supported |
X |
|
MySQL |
5.1 |
Not Supported |
X (Early Access) |
In the OpenSSO terminology, an identity can represent one of the following four entities: user, group, role, or filtered role. All of these entities will be stored in one of the supported identity stores also synonymous with the user store. An OpenSSO server instance can have more than one identity store in a realm or across multiple realms. The services running as part of the OpenSSO web application consume the identities stored in the identity repositories for authentication and authorization purposes.
Technically an OpenSSO server can exist without a data store configuration to start with, because the administrative user called amadmin (this username is hardcoded and cannot be changed) is stored in the configuration store. This enables the administrator to log in to the server even if the user store that provides authentication is down. All the identity names are case insensitive from the processing perspective. However, the administrative console and other utilities display the identities as you have created them. For instance, you can log in to OpenSSO by entering amAdmin or amadmin in the username field, and both will let you access the console as long as the password is correctly entered. Of course, passwords are case sensitive.
There is a separate section devoted to these identity stores due to their importance. We will revisit this topic in greater detail in the later part of this book.