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 22.214.171.124.0, 126.96.36.199.0, 188.8.131.52.0, 184.108.40.206.0 and 220.127.116.11.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.
|18.104.22.168.0||22.214.171.124.0||=>126.96.36.199.0||188.8.131.52.0||Certified (schema only upgrade)|
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 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 19.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 184.108.40.206.0
Sun DS 6.3, 7.0
Novell eDirectory 8.8
Tivoli Access Manager
Active Directory AM
Active Directory 2008
Oracle DB 10g, 11gR1, 11gR2
Open LDAP 2.2 requires a special set up; for details see Appendix H, "Using an OpenLDAP Identity Store."
For support for reference integrity in Oracle Internet Directory servers, see Important note Section 9.2, "Using an LDAP-Based OPSS Security Store."
For details about WebLogic Authenticators, consult the document Understanding Security for Oracle WebLogic Server.
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.
Select the appropriate 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
UseRetrievedUserNameAsPrincipalbe 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 Developing Security Providers for Oracle WebLogic Server.
Configuring Authentication Providers in Administering Security for Oracle WebLogic Server, and section Configure Authentication and Identity Assertion providers in Oracle WebLogic Server Administration Console Online Help.
Section Configure Authentication and Identity Assertion providers in 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 Administering Security for 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 Administering Security for 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 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 G.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 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 Administering Security for Oracle WebLogic Server.
For details about Kerberos identification, see section Creating a Kerberos Identification for WebLogic Server in Administering Security for Oracle WebLogic Server.
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
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 represented by 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.
There is exactly one policy store per domain. During development, application policies are file-based and specified in the file
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 9.6.1, "Migrating with Fusion Middleware Control." By default, the policy store is file-based.
For reassociation details, see Section 9.5, "Reassociating the OPSS Security Store."
Note:All permission classes must be specified in the system class path.
For details about the resource catalog support within a policy store, see Section 17.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 220.127.116.11 or later; and releases 18.104.22.168 or later).
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 9.6.1, "Migrating with Fusion Middleware Control."
Credentials can also be reassociated from one type of store to another. For details, see Section 9.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:
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 Internet Directory (Note: No other LDAP servers are supported.)
See Also:Chapter 12 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 9.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:
See Also:Chapter 13 for details about the audit service.