Understanding Identities, Policies, Credentials, Keys, Certificates, and Audit

Authentication Basics

OPSS uses WebLogic Server Authentication providers, components that validate users based on a user name/password combination or a certificate. Authentication providers make user identity information available (in subjects) to other components in the domain.

Java EE applications can use LDAP or DB authentication providers. Ready-to-use, Java SE applications use a file identity store, but the store can be configured to use an LDAP server or a database.

For information about Oracle WebLogic Server security, see Authentication in Understanding Security for Oracle WebLogic Server.

The following sections describe WebLogic Server Authentication providers:

WebLogic Server Authentication Providers

By default, users and groups are stored in the WebLogic Server Default Authenticator. This authentication provider uses cn as the default attribute.

The data stored in any LDAP authentication provider can be accessed by the User and Role API to query user profile attributes, but custom code may be required to query identity repositories that are not LDAP. Within an authentication provider, a group name must be unique.

The following sections explain how to set up multiple authentication providers:

See also:

How an LDAP X509 Identity Assertion Provider Works in Administering Security for Oracle WebLogic Server

Configuring the SAML Authentication Provider in Administering Security for Oracle WebLogic Server

Support for Multiple Authentication Providers

WebLogic Server allows the configuration of multiple authentication providers in a given context. One of them must be an LDAP authentication provider.

The Default Authenticator has the control flag set (by default) to REQUIRED. To initialize the identity store with an LDAP authentication provider other than the Default Authenticator, change the control flag of the Default Authenticator or switch the order of the authentication providers.

OPSS initializes the identity store with the LDAP authentication provider according to the following algorithm:

Consider the set of LDAP authentication providers configured in the context. The context must contain at least one LDAP authentication provider.
Within that set, consider those that have set the maximum flag. The flag ordering used to compute this subset is the following:
```
REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL
```
Within that subset, consider the first provider in the context.

The LDAP authentication provider singled out in step 3 is the one used to initialize the identity store.

If a service instance initialization value is provided explicitly in the service instance configuration, then the value configured takes precedence over the default one.

OPSS API References

Additional Authentication Methods

The WebLogic Server Identity Assertion providers support certificate authentication using X.509 certificates, SPNEGO tokens, Security Assertion Markup Language (SAML) assertion tokens, and CORBA Common Secure Interoperability version 2 (CSIv2).

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 Server users.

See also:

Identity Assertion Providers and LoginModules in Understanding Security for Oracle WebLogic Server

Overview of Single Sign-On with Microsoft Clients in Administering Security for Oracle WebLogic Server

Creating a Kerberos Identification for WebLogic Server in Administering Security for Oracle WebLogic Server

Identity Store Types and WebLogic Server Authentication Providers

The information in this section applies only to Java EE applications.

For supported versions of identity store types, see Oracle Fusion Middleware Supported System Configurations.

Table 3-1 lists the WebLogic Server Authentication providers used with each identity store type:

Table 3-1 Identity Store Types and Authentication Providers

Store Type	WebLogic Server Authentication Provider
Oracle Internet Directory	OracleInternetDirectoryAuthenticator
Oracle Virtual Directory	OracleVirtualDirectoryAuthenticator
Open LDAP	OpenLDAPAuthenticator
Oracle Unified Directory	iPlanetAuthenticator
Oracle Directory Server Enterprise Edition	iPlanetAuthenticator
Sun Java System Directory Server	iPlanetAuthenticator
Novell eDirectory	NovellAuthenticator
Tivoli Access Manager	OpenLDAPAuthenticator
Active Directory	ActiveDirectoryAuthenticator
Active Directory AM	ActiveDirectoryAuthenticator
Active Directory 2008	ActiveDirectoryAuthenticator
Oracle DB	CustomDBMSAuthenticator ReadOnlySQLAuthenticator SQLAuthenticator
Oracle Identity Cloud Service	OracleIdentityCloudIntegrator

Any LDAP authentication provider other than the Default Authenticator requires that you set the UseRetrievedUserNameAsPrincipal flag. Ready-to-use, this flag is set in the Default Authenticator.

Using an OpenLDAP Identity Store

Authentication Providers in Developing Security Providers for Oracle WebLogic Server

Configuring Authentication Providers in Administering Security for Oracle WebLogic Server

Configure authentication and identity assertion providers in Oracle WebLogic Server Administration Console Online Help

Policies Basics

A policy specifies the permissions granted to code loaded from a given location.

A Java Authorization and Authentication Services (JAAS) policy extends policies by allowing an optional list of principals, so that permissions are granted to code run by a user represented by those principals.

An application policy is a collection of JAAS policies that applies to the application only (in contrast to policies that apply to all applications in the domain).

A system policy grants permissions to users and groups, or to code, such as a URL or a JAR file.

The OPSS authorization service provides a central repository of system and application 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 the web.xml or ejb-jar.xml files) get mapped to enterprise users and groups and used by application policies.

The policy store refers to the portion of the security store where application and system policies are kept. The type of the policy store can be file, LDAP, or DB. A file store is an XML file. The only LDAP policy store type supported is Oracle Internet Directory.

During development and by default, application policies are specified in the jazn-data.xml file.

When you deploy the application with Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control), policies can be automatically migrated into the security store.

All permission classes must be specified in the system class path.

Reassociating the Security Store

The JAAS/OPSS Authorization Model

Credentials Basics

The OPSS credential service provides a central repository of artifacts 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.

The credential store refers to the portion of the security store where credentials are kept. The type of the credential store can be file, LDAP, or DB. A file credential store is the cwallet.sso file. The only LDAP credential store type supported is Oracle Internet Directory.

An application can use either the credential store or its own credential store. The credential store can be a file, LDAP, or DB.

When you deploy the application with Fusion Middleware Control, credentials can be automatically migrated into the security store.

OPSS provides the Credential Store Framework that includes an API that applications can use to create, read, update, and manage credentials programmatically.

Reassociating the Security Store

Keys and Certificates Basics

The keystore service (KSS) keystore provides a central repository for the keys and certificates used by a domain components and applications. This eliminates the need to associate keystores with individual applications, and it provides a single user interface that allows you to manage keystore data uniformly in the domain.

The keystore repository can be file, DB, or LDAP. The keystore can be reassociated from one type to another.

See also:

Reassociating the Security Store

Managing Keys and Certificates

Audit Basics

Oracle Fusion Middleware Audit Framework provides the audit store, a central repository of audit records for the domain. Use this framework to audit events triggered by configuration changes as well as operational activity for components and deployed applications. The audit store can be file or database.