Applications use the identity, policy, and credential stores configured in the domain in which they run. This chapter introduces the basic concepts regarding identity, policy, and credential data, and it 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."
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 must use LDAP-based authentication providers; Java SE applications use file-based identity stores out-of-the-box, but the identity store can be configured to be LDAP-based.
For further details, see section Authentication in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.
Note:OPSS does not support automatic migration of users and groups used in application development to a remote WebLogic Server where an application may be deployed. Instead, one must independently create the necessary application identities using the Oracle WebLogic Administration Console, OPSS scripts, or the appropriate tool depending on the authentication provider(s) configured in your domain.
This section covers the following topics:
Oracle Internet Directory 11g
Oracle Virtual Directory
Oracle Directory Server Enterprise Edition 126.96.36.199.0
Active Directory 2008
Novell eDirectory 8.8
OpenLDAP 2.2. For the special configuration required for this type, see Appendix J, "Using an OpenLDAP Identity Store."
Tivoli Access Manager
Sun DS 6.3, 7.0
Oracle DB 10g, 11gR1, 11gR2
iPlanet Directory Server
For information about Oracle Fusion Middleware Certification and Supported Configurations, visit
In regards to support for reference integrity in Oracle Internet Directory servers, see Important note Section 8.2, "Using an LDAP-Based OPSS Security Store."
For a list of WebLogic authenticator providers, see chapter 4, Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.
For details about the available authenticators, and choosing and configuring one, see section 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 Help.
The data stored in any LDAP authenticator can be accessed by the User and Role API to query user profile attributes. For details about WebLogic LDAP authenticators, see the following sections:
Important:If your domain uses the DefaultAuthenticator, then the domain administration server must be running for an application to query data using the User and Role API.
OPSS requires that a domain have at least one LDAP-based authenticator configured in a domain.
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 offers several LDAP-based authenticators. For a choice of available LDAP servers for the identity store, see Supported LDAP Identity Store Types. The Weblogic DefaultAuthenticator is the default authenticator configured and ready to use out-of-the-box after installation. Other authenticators can be configured using the WebLogic Administration Console.
For details about the use of authenticators in Java SE applications, see Section 22.2.2, "Configuring an LDAP Identity Store in Java SE Applications."
OPSS initializes the identity store service with the LDAP authenticator chosen from the list of configured LDAP 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.
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 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.
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 are 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.
Important:As long as a domain is pointing to a policy store, that policy store cannot be deleted from the environment.
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 188.8.131.52 or later; and releases 184.108.40.206 or later).
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 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.4.1, "Parameters Controlling Policy Migration," and Section 21.4.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 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 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."