Applications use the identity, policy, credential stores, keystores, and audit repository configured in the domain in which they run. This chapter introduces the basic concepts regarding identity, policy, credential, keystore, and audit data. In addition, it presents a matrix that shows the compatible versions of security artifacts. This chapter is divided into the following sections:
For definitions of the terms used in this chapter, see Section 2.1, "Terminology."
For scenarios illustrating the use of stores, see Chapter 4, "About Oracle Platform Security Services Scenarios."
This section states the compatible versions of binaries, configurations, schemas, and stores for releases 11.1.1.5.0, 11.1.1.6.0, and 11.1.1.7.0. The compatible versions of these artifacts apply to both DB-based and OID-based OPSS stores.
The OPSS security store is a composite store, that is, a store that includes all security artifacts such as policies, keys, credentials, and audit metadata. In DB-based stores, exactly one logical security store is assumed per DB schema.
The following table shows the versions compatible and it applies to both DB-based and OID-based security stores. Note the following terminology symbols:
The prefix => next to a version number denotes a version equal to or higher than the stated version number.
The prefix > next to a version number denotes a version higher than the stated version number.
The prefix < next to a version number denotes a version lower than the stated version number.
| Binary | Configuration | Schema | Store | Status |
|---|---|---|---|---|
|
11.1.1.5.0 |
11.1.1.5.0 |
=>11.1.1.5.0 |
11.1.1.5.0 |
Certified |
|
11.1.1.5.0 |
11.1.1.5.0 |
>11.1.1.5.0 |
>11.1.1.5.0 |
Not supported |
|
11.1.1.6.0 |
11.1.1.5.0 |
=>11.1.1.5.0 |
11.1.1.5.0 |
Certified |
|
11.1.1.6.0 |
11.1.1.5.0 |
>11.1.1.5.0 |
>11.1.1.5.0 |
Not supported |
|
11.1.1.6.0 |
11.1.1.6.0 |
=>11.1.1.6.0 |
11.1.1.6.0 |
Certified |
|
11.1.1.6.0 |
11.1.1.6.0 |
>11.1.1.6.0 |
>11.1.1.6.0 |
Not supported |
|
11.1.1.7.0 |
11.1.1.7.0 |
=>11.1.1.6.0 |
<11.1.1.7.0 |
Not supported |
|
11.1.1.7.0 |
11.1.1.6.0 |
=>11.1.1.6.0 |
11.1.1.6.0 |
Certified |
|
11.1.1.7.0 |
11.1.1.6.0 |
>11.1.1.6.0 |
>11.1.1.6.0 |
Not supported |
|
11.1.1.7.0 |
11.1.1.7.0 |
=>11.1.1.7.0 |
11.1.1.7.0 |
Certified |
OPSS uses server authentication providers, components that validate user credentials or system processes based on a user name-password combination or a digital certificate. Authentication providers also make user identity information available to other components in a domain (through subjects) when needed.
Java EE applications use LDAP- or DB-based authentication providers. Java SE applications use a file-based identity store out-of-the-box, but they can be configured to use also LDAP- or DB-based authenticator providers.
For further details, see section Authentication in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.
This section covers the following topics:
The information in this section applies only to Java EE applications. For details about using authenticators in Java SE applications, see Section 22.3.2, "Configuring an LDAP Identity Store in Java SE Applications."
The following list enumerates the repositories supported for an identity store (note that all are LDAP-based except for the last one):
Oracle Internet Directory 11g
Oracle Virtual Directory
Open LDAP 2.2
Oracle Unified Directory 11gR1
Oracle Directory Server Enterprise Edition 11.1.1.3.0
Sun DS 6.3, 7.0
Novell eDirectory 8.8
Tivoli Access Manager
Active Directory
Active Directory AM
Active Directory 2008
Oracle DB 10g, 11gR1, 11gR2
Open LDAP 2.2 requires a special set up; for details see Appendix J, "Using an OpenLDAP Identity Store."
For support for reference integrity in Oracle Internet Directory servers, see Important note Section 8.2, "Using an LDAP-Based OPSS Security Store."
The following table lists the WebLogic authenticators to use with each of the repositories:
Table 3-1 Identity Store Repositories and Authenticators
| Store Type | WebLogic Authenticator |
|---|---|
|
Oracle Internet Directory 11g |
OidAuthenticator |
|
Oracle Virtual Directory |
OvdAuthenticator |
|
Open LDAP 2.2 |
OpenldapAuthenticator |
|
Oracle Unified Directory 11gR1 |
iPlanetAuthenticator |
|
Oracle Directory Server Enterprise Edition 11.1.1.3.0 |
OdseeAuthenticator |
|
Sun DS 6.3, 7.0 |
SundsAuthenticator |
|
Novell eDirectory 8.8 |
eDirectoryAuthenticator |
|
Tivoli Access Manager |
TivoliAuthenticator |
|
Active Directory |
AdAuthenticator |
|
Active Directory AM |
AdamAuthentcator |
|
Active Directory 2008 |
Ad2008Authenticator |
|
Oracle DB 10g, 11gR1, 11gR2 |
CustomDBMSAuthenticator ReadOnlySQLAuthenticator SQLAuthenticator |
To create and configure a new authenticator using the WebLogic console, proceed as follows:
Create a new authenticator. For details see list of topics following this procedure.
Depending on your particular identity store repository and according to Table 3-1, select the apporpriate WebLogic authenticator; the parameters you enter depend on the authenticator selected; for example, in case of OidAuthenticator, you enter the host information, as illustrated in the following sample:
host name: example.com port: 5555 principal: cn=orcladmin credential: myPassword user base DN: cn=Users,dc=us,dc=oracle,dc=com group base DN: cn=Groups,dc=us,dc=oracle,dc=com
Save your input to create a new authenticator.
Set the appropriate control flag in the created authenticator.
Reorder the list of authenticators in your domain, as appropriate.
Restart the WebLogic server.
Important:
Any LDAP-based authenticator used in a domain, other than the DefaultAuthenticator, requires that the flag UseRetrievedUserNameAsPrincipal be set. Out-of-the-box, this flag is set in the DefaultAuthenticator.
For further information about WebLogic authenticators, consult the following topics:
Chapter 4, Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.
Configuring Authentication Providers in Oracle Fusion Middleware Securing Oracle WebLogic Server., and section Configure Authentication and Identity Assertion providers in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
Section Configure Authentication and Identity Assertion providers in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
By default and out-of-the-box, Oracle WebLogic Server stores users and groups in the DefaultAuthenticator. This authenticator is setup to use cn as the default attribute.
The data stored in any LDAP authenticator can be accessed by the User and Role API to query user profile attributes, but custom code may be required to query non-LDAP identity store repositories.
This section contains the following topics:
For details about X.509 identity assertion, see section How an LDAP X509 Identity Assertion Provider Works in Oracle Fusion Middleware Securing Oracle WebLogic Server.
For details about authentication using the SAML 1.1 or SAML 2.0 identity assertion provider, see section Configuring the SAML Authentication Provider in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Oracle WebLogic Server allows the configuration of multiple authenticators in a given context. One of them must be an LDAP-based authenticator.
OPSS initializes the identity store service with the LDAP authenticator chosen from the list of configured authenticators according to the following algorithm:
Consider the subset of LDAP authenticators configured. Note that, since the context is assumed to contain at least one LDAP authenticator, this subset is not empty.
Within that subset, consider those that have set the maximum flag. The flag ordering used to compute this subset is the following:
REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL
Again, this subset (of LDAPs realizing the maximum flag) is not empty.
Within that subset, consider the first configured in the context.
The LDAP authenticator singled out in step 3 is the one chosen to initialize the identity store service. For details about host name verification when establishing an SSL connection with an LDAP authenticator, see Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.
For details about the default values that OPPS uses to initialize the various supported LDAP authenticators, see javadoc User and Role API documentation in Section H.1, "OPSS API References." If a service instance initialization value is provided by default and also (explicitly) in the service instance configuration, the value configured takes precedence over the default one.
The WebLogic Identity Assertion providers support certificate authentication using X.509 certificates, SPNEGO tokens, SAML assertion tokens, and CORBA Common Secure Interoperability version 2 (CSIv2) identity assertion.
The Negotiate Identity provider is used for SSO with Microsoft clients that support the SPNEGO protocol. This provider decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users.
For general information about identity assertion providers, see section Identity Assertion Providers in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.
For an overview of SSO with Microsoft clients, see section Overview of Single Sign-On with Microsoft Clients in Oracle Fusion Middleware Securing Oracle WebLogic Server.
For details about Kerberos identification, see section Creating a Kerberos Identification for WebLogic Server in Oracle Fusion Middleware Securing Oracle WebLogic Server.
On WebSphere, OPSS supports LDAP-based registries only; in particular, it does not support WebSphere's built-in file-based user registry.
For details about configuration and seeding a registry, see Oracle Fusion Middleware Third-Party Application Server Guide
A Java 2 policy specifies the permissions granted to signed code loaded from a given location.
A JAAS policy extends Java 2 grants by allowing an optional list of principals; the semantics of the permissions are granted to only code from a given location, possibly signed, and run by a user represented by those principals.
JACC extends the Java 2 and JAAS permission-based policy to EJBs and Servlets by defining an interface to plug custom authorization providers, that is, pluggable components that allow the control and customizing of authorizations granted to running Java EE applications.
An application policy is a collection of Java 2 and JAAS policies, which is applicable to just that application (in contrast to a Java 2 policy, which is applicable to the whole JVM).
The policy store is a repository of system and application-specific policies and roles. Application roles can include enterprise users and groups specific to the application (such as administrative roles). A policy can use any of these groups or users as principals.
In the case of applications that manage their own roles, Java EE application roles (configured in files web.xml or ejb-jar.xml) get mapped to enterprise users and groups and used by application-specific policies.
A policy store can be file-, LDAP-, or DB-based. A file-based policy store is an XML file, and this store is the out-of-the-box policy store provider. The only LDAP-based policy store type supported is Oracle Internet Directory. The only DB-based policy store type supported is Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).
Policy Store Scope, Migration, and Reassociation
There is exactly one policy store per domain. During development, application policies are file-based and specified in the file jazn-data.xml.
When the application is deployed on WebLogic with Fusion Middleware Control, they can be automatically migrated into the policy store. For details about this feature, see Section 8.6.1, "Migrating with Fusion Middleware Control." By default, the policy store is file-based.
When the application is deployed on WebSphere, the behavior of migration at deployment can be manually specified as described in Section 21.5.1, "Parameters Controlling Policy Migration," and Section 21.5.4, "Parameters Controlling Credential Migration."
For reassociation details, see Section 8.5, "Reassociating the OPSS Security Store."
For details about the resource catalog support within a policy store, see Section 20.3.1, "The Resource Catalog."
A credential store is a repository of security data (credentials) that certify the authority of users, Java components, and system components. A credential can hold user name and password combinations, tickets, or public key certificates. This data is used during authentication, when principals are populated in subjects, and, further, during authorization, when determining what actions the subject can perform.
OPSS provides the Credential Store Framework, a set of APIs that applications can use to create, read, update, and manage credentials securely.
A credential store can be file-, LDAP-, or DB-based. A file-based credential store, also referred to as wallet-based and represented by the file cwallet.sso, is the out-of-the-box credential store. The only LDAP-based credential store type supported is Oracle Internet Directory. The only DB-based credential store type supported is Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).
Credential Store Scope, Migration, and Reassociation
An application can use either the domain credential store or its own wallet-based credential store. The domain credential store can be wallet-based (by default), LDAP-, or DB-based. The only LDAP-based credential store type supported is Oracle Internet Directory.
The migration of application credentials to the credential store can be configured to take place automatically when the application is deployed. For details, see Section 8.6.1, "Migrating with Fusion Middleware Control."
Credentials can also be reassociated from one type of store to another. For details, see Section 8.5, "Reassociating the OPSS Security Store."
The Keystore Service provides a central repository for keystores and trust stores containing all the keys and certificates used by a domain's components and applications. This eliminates the need to associate keystores with individual applications.
The administrator works with a single user interface providing a unified way to view and manage all keystores.
The central repository can be any of the following:
XML file-based
This is the out-of-the-box keystore repository, and it is named keystores.xml.
Note:
This file is not present immediately after installation; rather, it is generated the first time the Administration Server is started.
Oracle Database
Oracle Internet Directory (Note: No other LDAP servers are supported.)
See Also:
Chapter 11 for details about the Keystore Service.
Keys and certificates in the domain keystore repository can be reassociated from one type to another. For details, see Section 8.5, "Reassociating the OPSS Security Store".
The Audit Service supports a central repository of audit records for the domain. Administrators can conveniently leverage the service to audit events triggered by configuration changes as well as operational activity for components and deployed applications.
The repository for audit records can be:
file-based
Oracle Database
See Also:
Chapter 12 for details about the audit service.