Applications use the identity, policy, and credential stores configured in the domain in which they run. This chapter introduces the repository that store security data for identity, policy, and credential data. OPSS supports file- and LDAP-based policy and credential stores.
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."
OPSS uses WebLogic 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.
Authentication providers include the DefaultAuthenticator; external LDAP stores; and DBMS to host data for enterprise applications. For a full list of authenticator providers, see chapter 4, Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.
JavaEE applications use WebLogic authentication providers; JavaSE 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, WLST commands, or the appropriate tool depending on the authentication provider(s) configured in your domain.This section covers the following topics:
OPSS includes several authentication providers. 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.
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. For details about LDAP authenticators, see Using an LDAP Authenticator.
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.
The following list enumerates the LDAP repositories supported for an identity store:
Sun Java System Directory Service version 6.3
Active Directory 2003, 2008
Novell eDirectory 8.8
OpenLDAP 2.2
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.
This section explains the initialization of the identity store service and how to access an LDAP authenticator programmatically.
Oracle WebLogic Server offers several LDAP-based authenticators. For a choice of available LDAP servers, see Section 4.1, "Supported LDAP- and File-Based Servers." The 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 JavaSE applications, see Section 15.2.2, "Configuring an LDAP Identity Store in JavaSE Applications."
Oracle WebLogic Server allows the configuration of multiple authenticators in a given context, each of which has a control flag set. 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 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.
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 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.
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 JavaEE 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, JavaEE application roles (configured in files web.xml or 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-based or LDAP-based. A file-based policy store is an XML file, and this store is the out-of-the-box policy store provider. An LDAP-based policy store can use either of the following LDAP servers: Oracle Internet Directory or Oracle Virtual Directory (with a local store adapter, or LSA).
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 with Fusion Middleware Control, they can be automatically migrated into the domain policy store. For details about this feature, see Section 7.3.1, "Migrating Application Policies with Fusion Middleware Control." By default, the domain policy store is file-based.
Reassociation of policies is supported from a file-based store or from an LDAP-based (Oracle Internet Directory) store only. The reassociation of domain policies from an LDAP-based policy store using any other type of LDAP server provider is not supported. For details, see Section 7.2, "Reassociating the Domain Policy Store."
For details about the resource catalog support within a policy store, see Section 17.2.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-based or LDAP-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. An LDAP-based credential store can only use Oracle Internet Directory.
Scope, Migration, and Reassociation
An application can use either the domain credential store or, only during development, its own wallet-based credential store. The domain credential store can be wallet-based (by default) or LDAP-based.
The migration of application credentials to the domain credential store can be configured to take place automatically when the application is deployed. For details, see Section 8.4.1, "Migrating Application Credentials with Fusion Middleware Control."
Domain credentials can also be reassociated from one type of store to another. For details, see Section 8.3, "Reassociating the Domain Credential Store."