3 Understanding Identities, Policies, Credentials, Keys, Certificates, and Audit
This chapter includes the following sections:
Parent topic: Understanding Security Concepts
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.
Jakarta 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
Parent topic: Authentication Basics
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.
Parent topic: WebLogic Server Authentication Providers
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
Parent topic: WebLogic Server Authentication Providers
Identity Store Types and WebLogic Server Authentication Providers
The information in this section applies only to Jakarta 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.
See also:
Configuring the LDAP Identity Store in Java SE Applications
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 an Authentication or Identity Assertion Provider in Oracle WebLogic Remote Console Online Help
Parent topic: Authentication Basics
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, Jakarta 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.
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.
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.
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.