|
|
This section provides a description of the architecture of the WebLogic Security Service. The architecture comprises three major components, which are discussed in the following sections:
Figure 5-1 shows a high-level view of the WebLogic Security Framework. The framework comprises interfaces, classes, and exceptions in the weblogic.security.service package.
The primary function of the WebLogic Security Framework is to provide a simplified application programming interface (API) that can be used by security and application developers to define security services. Within that context, the WebLogic Security Framework also acts as an intermediary between the WebLogic containers (Web and EJB), the Resource containers, and the security providers.
The following sections describe the interactions between the WebLogic containers and Resource containers and each of the security providers via the WebLogic Security Framework:
Figure 5-2 shows the authentication process for a fat-client login. JAAS runs on the server to perform the login. Even in the case of a thin-client login (that is, a Web browser client) JAAS is still run on the server.
| Notes: | Only developers of custom Authentication providers will be involved with this JAAS process directly. The client application could either use a JNDI Initial Context or JAAS to initiate the passing of the username and password. |
When a user attempts to log into a system using a username/password combination, WebLogic Server establishes trust by validating that user’s username and password, and returns a subject that is populated with principals per JAAS requirements. As Figure 5-2 also shows, this process requires the use of a LoginModule and a Principal Validation provider. For more information on Principal Validation providers, see WebLogic Principal Validation Provider.
After successfully proving a caller’s identity, an authentication context is established, which allows an identified user or system to be authenticated to other entities. Authentication contexts may also be delegated to an application component, allowing that component to call another application component while impersonating the original caller.
Identity Assertion providers are used as part of perimeter authentication process. When perimeter authentication is used (see Figure 5-3), a token from outside of the WebLogic Server domain is passed to an Identity Assertion provider in a security realm that is responsible for validating tokens of that type and that is configured as “active.” If the token is successfully validated, the Identity Assertion provider maps the token to a WebLogic Server username, and sends that username back to WebLogic Server, which then continues the authentication process. Specifically, the username is sent via a JAAS CallbackHandler and passed to each configured Authentication provider’s LoginModule so that the LoginModule can populate the subject with the appropriate principals.
| Note: | To use the WebLogic Identity Assertion provider for X.501 and X.509 certificates, you have the option of using either the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or your own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more information, see
Do I Need to Develop a Custom Identity Assertion Provider? in Developing Security Providers for WebLogic Server. |
As Figure 5-3 also shows, perimeter authentication requires the same components as the authentication process, but also adds an Identity Assertion provider.
As shown in Figure 5-4, a user attempts to log into a system using a username/password combination. WebLogic Server establishes trust by calling the configured Authentication provider’s LoginModule, which validates the user’s username and password and returns a subject that is populated with principals per JAAS requirements.
WebLogic Server then passes the subject to the specified Principal Validation provider, which signs the principals and returns them to the client application via WebLogic Server. Whenever the principals stored within the subject are required for other security operations, the same Principal Validation provider will verify that the principals stored within the subject have not been modified since they were signed.
Figure 5-5 illustrates how Authorization providers (and the associated Adjudication and Role Mapping providers) interact with the WebLogic Security Framework during the authorization process.
The authorization process is initiated when a user or system process requests a WebLogic resource on which it will attempt to perform a given operation. The resource container that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the WebLogic Security Framework and passes in the request parameters, including information such as the subject of the request and the WebLogic resource being requested. The WebLogic Security Framework calls the configured Role Mapping providers and passes in the request parameters in a format that the Role Mapping providers can use. The Role Mapping providers use the request parameters to compute a list of roles to which the subject making the request is entitled and passes the list of applicable roles back to the WebLogic Security Framework. The Authorization provider determines whether the subject is entitled to perform the requested action on the WebLogic resource, that is, the Authorization provider makes the Access Decision. If there are multiple Authorization providers configured, the WebLogic Security Framework delegates the job of reconciling any conflicts in the Access Decisions rendered by the Authorization providers to the Adjudication provider and the Adjudication provider determines the ultimate outcome of the authorization decision.
If there are multiple Authorization providers configured (see Figure 5-5), an Adjudication provider is required to tally the multiple Access Decisions and render a verdict. The Adjudication provider returns either a TRUE or FALSE verdict to the Authorization providers, which forward it to the resource container through the WebLogic Security Framework.
TRUE, the resource container dispatches the request to the protected WebLogic resource.FALSE, the resource container throws a security exception that indicates that the requestor was not authorized to perform the requested access on the protected WebLogic resource.The WebLogic Security Framework calls each Role Mapping provider that is configured for a security realm as part of an authorization decision. For related information, see The Authorization Process.
Figure 5-6 shows how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations.
The role mapping process is initiated when a user or system process requests a WebLogic resource on which it will attempt to perform a given operation. The resource container that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the WebLogic Security Framework and passes in the request parameters, including information such as the subject of the request and the WebLogic resource being requested. The WebLogic Security Framework calls each configured Role Mapping provider to obtain a list of the roles that apply. If a security policy specifies that the requestor is entitled to a particular role, the role is added to the list of roles that are applicable to the subject. This process continues until all security policies that apply to the WebLogic resource or the resource container have been evaluated. The list of roles is returned to the WebLogic Security Framework, where it can be used as part of other operations, such as access decisions.
The result of the dynamic role association (performed by the Role Mapping providers) is a set of roles that apply to the principals stored in a subject at a given moment. These roles can then be used to make authorization decisions for protected WebLogic resources, as well as for resource container and application code. For example, an Enterprise JavaBean (EJB) could use the Java EE isCallerInRole method to retrieve fields from a record in a database, without having knowledge of the business policies that determine whether access is allowed.
Figure 5-7 shows how Auditing providers interact with the WebLogic Security Framework and other types of security providers (using an Authentication provider as an example).
The auditing process is initiated when a resource container passes a user’s authentication information (for example, a username/password combination) to the WebLogic Security Framework as part of a login request. The WebLogic Security Framework passes the information associated with the login request to the configured Authentication provider. If, in addition to providing authentication services, the Authentication provider is designed to post audit events, the Authentication provider instantiates an AuditEvent object. The AuditEvent object includes information such as the event type to be audited and an audit severity level. The Authentication provider then calls the Auditor Service in the WebLogic Security Framework, passing in the AuditEvent object. The Auditor Service passes the AuditEvent object to the configured Auditing providers’ runtime classes, enabling audit event recording. The Auditing providers’ runtime classes use the information obtained from the AuditEvent object to control audit record content. When the criteria for auditing specified by the Authentication providers in the AuditEvent object is met, the appropriate Auditing provider’s runtime class writes out audit records. Depending on the Auditing provider implementation, audit records may be written to a file, a database, or some other persistent storage medium.
Figure 5-8 illustrates how Credential Mapping providers interact with the WebLogic Security Framework during the credential mapping process.
The credential mapping process is initiated when application components, such as JavaServer Pages (JSPs), servlets, Enterprise JavaBeans (EJBs), or Resource Adapters call into the WebLogic Security Framework (through the appropriate resource container) to access an Enterprise Information System (EIS), for example, some relational database like Oracle, SQL Server, and so on. As part of the call, the application component passes in the subject (that is, the “who” making the request), the WebLogic resource (that is, the “what” that is being requested) and information about the type of credentials needed to access the WebLogic resource. The WebLogic Security Framework sends the application component’s request for credentials to a configured Credential Mapping provider that handles the type of credentials needed by the application component. The Credential Mapping provider consults its database to obtain a set of credentials that match those requested by the application component and returns the credentials to the WebLogic Security Framework. The WebLogic Security Framework passes the credentials back to the requesting application component through the resource container. The application component uses the credentials to access the external system.
During the certificate lookup and validation process, CertPath Builders, CertPath Validators, and the Certificate Lookup and Validation (CLV) framework all interact.
The process for building certificate chains works as follows:
The certificate chain is only valid if the CertPath Builder and all the configured CertPath Validators successfully validate it.
The process for validating certificate chains works as follows:
The certificate chain is only valid if all the configured CertPath Validators successfully validate it. Validation stops if an error occurs.
The SAML and Windows Integrated Login features provide web-based single sign-on (SSO) functionality for WebLogic Server applications. The following sections describe the interactions among the WebLogic containers, the security providers, and the WebLogic Security Framework during the single sign-on process:
The following sections describe how a WebLogic Server instance behaves during when configured with SAML 1.1 services:
Acting as a SAML source involves the following:
WebLogic Server can act as a SAML ITS and ARS. These services are provided by a servlet that is deployed based on configuration settings on the Server 
Configuration Federated Services pages in the Administration Console.
The SAML ITS service requires separate URLs for the POST and Artifact profiles for V1 SAML providers; separate URLs are not required for the POST and Artifact profiles with V2 SAML providers.
The following sections detail how WebLogic Server is used as a SAML source in the POST and Artifact profiles.
The POST profile works as follows:
http://www.weblogic.com/samlits/its) for the SAML source site.The Artifact profile works as follows:
www.weblogic.com) for the SAML source site.WebLogic Server acts as a SAML destination site when an unauthenticated Web browser or HTTP client tries to access a protected WebLogic resource and SAML is configured as the authentication mechanism in the security realm.
The SAML destination site is implemented as a servlet authentication filter (referred to as the SAML authentication filter) deployed by the SAML Identity Assertion provider based on its configuration. The SAML destination site listens for incoming assertions at one or more configured URLs.These URLs provide the Access Consumer Service (ACS). The SAML destination site can also be configured to redirect unauthenticated users to remote SAML source sites for authentication based on the particular URL they tried to access.
The following sections detail how WebLogic Server is used as a SAML destination in the POST and Artifact profiles.
In a typical SSO scenario, the POST profile works as follows:
http://www.weblogic.com/samlits/its) for the SAML source site.403 Forbidden. assertIdentity() call). The SAML authentication filter creates a session for the user and redirects the now authenticated user to the requested target URL.The Artifact profile works as follows:
http://www.weblogic.com/samlits/its) for the SAML source site.403 Forbidden. assertIdentity() call). The SAML authentication filter creates a session for the user and redirects the now authenticated user to the requested target URL.The SAML 2.0 Web Single Sign-On (SSO) profile supported by WebLogic Server implements the Authentication Request Protocol in conjunction with the HTTP Redirect, HTTP POST, and HTTP Artifact bindings. The following sections describe the flow of execution in both ways of that this profile can be initiated, showing the interaction among the SAML 2.0 services provided in WebLogic Server and the WebLogic Security Service:
In a typical Service Provider initiated SSO scenario, an unauthenticated user tries to access a protected resource on a Service Provider site. In response, the Service Provider initiates a Web SSO session by identifying the appropriate Identity Provider partner and sending or redirecting an authentication request to that partner. The Identity Provider then authenticates the user, typically via a login web application, generates a SAML assertion containing that user’s identity information, and returns the assertion to the Service Provider in the form of an authentication response.
When the Service Provider receives the authentication response, the Service Provider extracts the identity information from the assertion contained in the response and verifies the user’s identity by mapping it to a Subject in the local security realm. If the user’s identity is successfully mapped, the Service Provider can consequently authorize the user’s access to the protected resource.
Figure 5-9 shows the flow of execution in an example of a Service Provider initiated Web single sign-on session.
Note the following callouts in Figure 5-9 showing the flow of execution:
The Service Provider can be configured to use one of the following bindings for transmitting the authentication request:
The Identity Provider can be configured to use the following bindings:
The ACS validates the assertion, extracts the identity information from that assertion, and maps that identity to a subject in the local security realm.
The WebLogic Security Service performs an authorization check to determine whether the browser may access the requested resource. If the authorization check succeeds, access to the resource is granted.
WebLogic Server also supports the scenario in which a web single sign-on session is initiated by an Identity Provider. In this scenario, a user is authenticated by an Identity Provider and issues a request on a resource that is hosted by a Service Provider. The Identity Provider initiates the SSO session by sending an unsolicited authentication response to the Service Provider.
When the Service Provider receives the authentication response, the Service Provider extracts the identity of the user from the assertion, maps that identity to a local subject, and performs an authorization check on the requested resource. If the authorization check succeeds, access is granted.
Figure 5-10 shows the flow of execution in a typical Identity Provider initiated SSO session.
Note the following callouts in Figure 5-10 showing the flow of execution:
The user issues a request on a resource that is hosted by a Service Provider.
Regardless of how the SSO session is initiated, the Identity Provider uses the same bindings as described in step 6 in Service Provider Initiated Single Sign-On.
WWW-Authenticate and Authorization HTTP headers. The Negotiate Identity Assertion provider uses a servlet authentication filter to generate the appropriate WWW-Authenticate header on unauthorized responses for the negotiate protocol and handles the Authorization headers on subsequent requests.GET request to the application server.WWW-Authenticate headers.WWW-Authenticate request header for the negotiate authentication scheme and calls into the WebLogic Security Framework to get the initial Negotiate challenge. The following message is sent back:
401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate header and determines whether or not it can support the Negotiate authentication scheme. The browser then creates a SPNEGO token containing the supported GSS mechanism token types. It Base64 encodes the token and sends it back to the application server via an Authorization header on the original GET message as follows:
GET...
Authorization: Negotiate <Base64 encoded SPNEGO token>
The WebLogic Security Framework also determines to which groups the user belongs.
The WebLogic Web Services and the WebLogic Security Framework have been enhanced to support the generation, consumption, and validation of SAML 1.1 and 2.0 assertions. When using SAML assertions, a web service passes a SAML assertion and the accompanying proof material to the WebLogic Security Framework.If the SAML assertion is valid and trusted, the framework returns an authenticated Subject with a trusted principal back to the web service. WebLogic Web Services and the WebLogic Security Framework support the following SAML assertions:
Conceptually, the asserting party inserts an X.509 public certificate (or other key info) into a SAML assertion. (More correctly, the asserting party binds a key to a subject.) In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the Web Service client signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate contained in, or identified by, the assertion.
<SubjectConfirmationData> element of the assertion.The following sections describe how the processing of these assertions work.
All the Sender-Vouches assertions are basically the same, the difference is in how trust is established (meaning whether or not SSL is used for transport and whether or not the SAML assertion and the message bodies are signed).
The Sender-Vouches assertions are used in the following manner:
In the Holder-of-Key assertion, the Web Service client depends on the Web Service server to ensure that the user is to be trusted.
The Holder-of-Key assertions are used in the following manner:
wsse:Security header in a SOAP message. The message body is signed with the private key of the user. If this succeeds, the Web Service server can assume that the key in the holder-of-key assertion does in fact belong to the Subject of the assertion. Web Services can then use that key to verify the signature that signs the SOAP message, which establishes that the SOAP message was generated/sent by the holder of the key. It is up to the Web Service server to verify trust in the X.509 certificate itself.
The Web Service server returns a Subject with principals for the SAML assertion to the Web Service client.
Optionally, the SSL protocol can be used with this assertion. If the SSL protocol is used, the client certificate can also be used as proof material.
Security in this release of WebLogic Server is based on a set of Security Service Provider Interfaces (SSPIs). The SSPIs can be used by developers and third-party vendors to develop security providers for the WebLogic Server environment. SSPIs are available for Adjudication, Auditing, Authentication, Authorization, Credential Mapping, Identity Assertion, Role Mapping, and Certificate Lookup and Validation.
| Note: | The SSPI for Keystore providers is deprecated in this release of WebLogic Server. Use Java KeyStores (JKS) instead. For information on how to use Java KeyStores, see Configuring Keystores in Securing WebLogic Server. |
The SSPIs allow customers to use custom security providers for securing WebLogic Server resources. Customers can use the SSPIs to develop custom security providers or they can purchase customer security providers from third-party vendors.
For more information on developing custom security providers, see Developing Security Providers for WebLogic Server.
This section provides descriptions of the security providers that are included in the WebLogic Server product for your use. Security providers are modules that “plug into” a WebLogic Server security realm to provide security services to applications. They call into the WebLogic Security Framework on behalf of applications.
If the security providers supplied with the WebLogic Server product do not fully meet your security requirements, you can supplement or replace them with custom security providers. You develop a custom security provider by:
weblogic.security.spi package to create runtime classes for the security provider.For more information, see Developing Security Providers for WebLogic Server.
Figure 5-11 shows the security providers that are required and those that are optional in a WebLogic security realm.
The security providers are described in the following sections:
The default (active) security realm for WebLogic Server includes a WebLogic Authentication provider. The WebLogic Authentication provider supports delegated username/password and WebLogic Server security digest authentication. It utilizes an embedded LDAP server to store user and group information. This provider allows you to edit, list, and manage users and group membership.
| Note: | In conjunction with the WebLogic Authorization provider, the WebLogic Authentication provider replaces the functionality of the File realm that was available in 6.x releases of WebLogic Server. |
WebLogic Server provides the following additional Authentication providers which can be used instead of or in conjunction with the WebLogic Authentication provider in the default security realm:
The following DBMS Authentication providers are available:
| Note: | By default, these additional Authentication providers are available but not configured in the WebLogic default security realm. |
WebLogic Server includes a Password Validation provider, which manages and enforces a set of password composition rules when configured with one or more of the following authentication providers:
When the Password Validation provider is configured with an authentication provider, the authentication provider invokes the Password Validation provider whenever a password is created or updated. The Password Validation provider then performs a check to determine whether the password meets the criteria established by a set of configurable composition rules.
The WebLogic Identity Assertion provider supports certificate authentication using X.509 certificates and CORBA Common Secure Interoperability version 2 (CSIv2) identity assertion. The WebLogic Identity Assertion provider validates the token type, then maps X.509 digital certificates and X.501 distinguished names to WebLogic users. It also specifies a list of trusted client principals to use for CSIv2 identity assertion. The wildcard character (*) can be used to specify that all principals are trusted. If a client is not listed as a trusted client principal, the CSIv2 identity assertion fails and the invoke is rejected.
The WebLogic Identity Assertion provider supports the following token types:
AU_TYPE—for a WebLogic AuthenticatedUser used as a token.X509_TYPE—for an X.509 client certificate used as a token.CSI_PRINCIPAL_TYPE—for a CSIv2 principal name identity used as a token. CSI_ANONYMOUS_TYPE—for a CSIv2 anonymous identity used as a token. CSI_X509_CERTCHAIN_TYPE—for a CSIv2 X.509 certificate chain identity used as a token. CSI_DISTINGUISHED_NAME_TYPE—for a CSIv2 distinguished name identity used as a token. WSSE_PASSWORD_DIGEST—for a wsse:UsernameToken with a password type of wsse:PasswordDigest used as a token.The SAML Identity Assertion provider V2 validates SAML 1.1 assertions and verifies the issuer is trusted. If so, identity is asserted based on the authentication statement contained in the assertion.
Provider configuration includes settings that configure and enable SAML source site and destination site SSO services (such as ITS, ACS, and ARS) to run in the server.
The SAML Identity Assertion provider supports the following SAML Subject confirmation methods:
Similar to the SAML Identity Assertion provider V2 for SAML 1.1, the SAML 2.0 Identity Assertion provider validates SAML 2.0 assertions and verifies that the issuer is trusted. If so, identity is asserted based on the authentication statement contained in the assertion.
Provider configuration includes settings that configure and enable SAML 2.0 Service Provider services, such as the Assertion Consumer Service and Artifact Resolution Service, to run in the server.
The SAML 2.0 Identity Assertion provider supports the following SAML Subject confirmation methods:
The Negotiate Identity Assertion provider is used for SSO with Microsoft clients that support the SPNEGO protocol. Specifically, it decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. The Negotiate Identity Assertion provider utilizes the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context via Kerberos. For more information about the Java GSS API, see http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/jgss-features.html.
The Negotiate Identity Assertion provider interacts with the WebLogic Servlet container which handles WWW-Authenticate and WWW-Authorization headers, adding the appropriate Negotiate header.
By default, the Negotiate Identity Assertion provider is available but not configured in the WebLogic default security realm. The Negotiate Identity Assertion provider can be used instead of or in addition to the WebLogic Identity Assertion provider.
The default (active) security realm for WebLogic Server includes a WebLogic Principal Validation provider. This provider signs and verifies WebLogic Server principals. In other words, it signs and verifies principals that represent WebLogic Server users or WebLogic Server groups.
| Note: | You can use the WLSPrincipals class (located in the weblogic.security package) to determine whether a principal (user or group) has special meaning to WebLogic Server (that is, whether it is a predefined WebLogic Server user or WebLogic Server group). Furthermore, any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces (available in the weblogic.security.spi package). |
The WebLogic Principal Validation provider includes implementations of the WLSUser and WLSGroup interfaces, named WLSUserImpl and WLSGroupImpl. These are located in the weblogic.security.principal package. It also includes an implementation of the PrincipalValidator SSPI called PrincipalValidatorImpl. For more information about the PrincipalValidator SSPI, see
“Implement the PrincipalValidator SSPI” in Developing Security Providers for WebLogic Server.
Much as an Identity Assertion provider supports a specific type of token, a Principal Validation provider signs and verifies the authenticity of a specific type of principal. Therefore, you can use the WebLogic Principal Validation provider to sign and verify principals that represent WebLogic Server users or WebLogic Server groups.
As of version 9.1, WebLogic Server includes an Authorization provider that supports the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic This provider can import, export, persist and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.
New domains created using WebLogic Server 9.1 and later will default to using the XACML Authorization provider. Existing domains, upgraded WebLogic Server 9.1 and later, will continue to use the Authorization provider currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. If you use the WebLogic Server Administration Console to add a new Authorization provider, you can add the new provider as a DefaultAuthorizer or as a XACML provider.
Custom XACML providers are not supported in this release.
Version 9.1 of WebLogic Server also includes the “default” WebLogic Authorization provider. This provider supplied the default enforcement of authorization for versions of WebLogic Server prior to 9.1. Using a policy-based authorization engine, the WebLogic Authorization provider returns an access decision to determine if a particular user is allowed access to a protected WebLogic resource. The WebLogic Authorization provider also supports the deployment and undeployment of security policies within the system.
The default (active) security realm for WebLogic Server includes a WebLogic Adjudication provider. This provider would normally be responsible for tallying the potentially differing results rendered by multiple Authorization providers’ Access Decisions and rendering a final verdict on whether or not access will be granted to a WebLogic resource. However, because the default security realm only has one Authorization provider, only one Access Decision is produced so the WebLogic Adjudication provider is not used.
| Note: | The WebLogic Adjudication provider is used in the Compatibility realm, which has two Authorization providers. |
The WebLogic Adjudication provider has an attribute called Require Unanimous Permit that governs its behavior. By default, the Require Unanimous Permit attribute is set to TRUE, which causes the WebLogic Adjudication provider to act as follows:
PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).PERMIT and others return ABSTAIN, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).ABSTAIN or DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).
If you change the Require Unanimous Permit attribute to FALSE, the WebLogic Adjudication provider acts as follows:
PERMIT, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).PERMIT and others return ABSTAIN, then return a final verdict of TRUE (that is, permit access to the WebLogic resource).DENY, then return a final verdict of FALSE (that is, deny access to the WebLogic resource).| Note: | You set the Require Unanimous Permit attributes when you configure the WebLogic Adjudication provider. For more information about configuring an Adjudication provider, see “Configuring a WebLogic Adjudication Provider” in Securing WebLogic Server. |
As of version 9.1, WebLogic Server includes a Role Mapping provider that supports the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic This provider can import, export, persist and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.
New domains created using WebLogic Server 9.1 and later will default to using the XACML Role Mapping provider. Existing domains, upgraded to WebLogic Server 9.1 and later, will continue to use the Role Mapping provider currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. If you use the WebLogic Server Administration Console to add a new Role Mapping provider, you can add the new provider as a DefaultRoleMapper or as a XACML provider.
Custom XACML providers are not supported in this release.
Version 9.1 of WebLogic Server also includes the “default” WebLogic Role Mapping provider. This provider supplied the default enforcement of role mapping for versions of WebLogic Server prior to WebLogic Server 9.1. This provider determines dynamic roles for a specific user (subject) with respect to a specific protected WebLogic resource for each of the default users and WebLogic resources. The WebLogic Role Mapping provider supports the deployment and undeployment of roles within the system. The WebLogic Role Mapping provider uses the same security policy engine as the WebLogic Authorization provider.
The default (active) security realm for WebLogic Server includes a WebLogic Auditing provider. This provider records information from a number of security requests, which are determined internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data associated with these security requests, and the outcome of the requests.
The default (active) security realm for WebLogic Server includes a WebLogic Credential Mapping provider. You use the WebLogic Credential Mapping provider to associate, or map, a WebLogic Server user to the appropriate credentials to be used with a Resource Adapter to access an Enterprise Information System (EIS), for example, some relational database like Oracle, SQL Server, and so on. The provider maps a user’s authentication credentials (username and password) to those required for legacy applications, so that the legacy application gets the necessary credential information. For example, the EIS may be a mainframe transaction processing, database systems, or legacy applications not written in the Java programming language.
If you only want to map WebLogic Server users and groups to username/password credentials in another system, then the WebLogic Credential Mapping provider is sufficient.
The SAML Credential Mapping provider V2 generates SAML 1.1 assertions for authenticated subjects based on relying party/destination site configuration. Assertions contain an authentication statement and, optionally, an attribute statement containing WebLogic Server group information. If the requested target has not been configured and no defaults are set, an assertion will not be generated. User information and group membership (if configured as such) are put in the AttributeStatement.
The Administration Console Federation Services configuration pages include settings that configure and enable SAML source site and destination site SSO services (such as ITS, ACS, and ARS) to run in the server.
The provider supports the following SAML Subject confirmation methods:
The SAML 2.0 Credential Mapping provider generates SAML 2.0 assertions for authenticated subjects based on the configuration of Identity Provider services and the set of Service Provider partners. Assertions contain an authentication statement and, optionally, an attribute statement containing WebLogic Server group information. If the requested target has not been configured and no defaults are set, an assertion will not be generated. User information and group membership (if configured as such) are put in the AttributeStatement.
The Administration Console Federation Services configuration pages for SAML 2.0 include settings that configure and enable SAML 2.0 source site and destination site services (such as Single Sign-On, and Artifact Resolution Service) to run in the server.
The provider supports the following SAML Subject confirmation methods:
The PKI (Public Key Infrastructure) Credential Mapping provider maps a WebLogic Server subject (the initiator) and target resource (and an optional credential action) to a public/private key pair or public certificate that should be used by the application when using the targeted resource. This provider can also map an alias to a public/private key pair or public certificate. The PKI Credential Mapping provider uses the subject and resource name, or the alias, to retrieve the corresponding credential from the keystore.
The WebLogic CertPath provider is both a CertPath Builder and a CertPath Validator. The provider completes certificate paths and validates the certificates using the trusted CA configured for a particular server instance.If a certificate chain cannot be completed, it is invalid.
The WebLogic CertPath provider also checks the signatures in the chain, ensures that the chain has not expired, and checks that one of the certificates in the chain is issued by one of the trusted CAs configured for the server. If any of these checks fail, the chain is not valid.
Finally, the provider checks that the each certificate’s basic constraints (that is, the ability of the certificate to issue other certificates) to ensure the certificate is in the proper place in the chain.
The WebLogic CertPath provider can be used as CertPath Builder or a CertPath Validator in a security realm.
The Certificate Registry allows the system administrator to explicitly configure a list of trusted CA certificates that are allowed access to the server. The Certificate Registry provides an inexpensive mechanism for performing revocation checking. An administrator revokes a certificate by removing it from the certificate registry. The registry is stored in the embedded LDAP server.
Certificate Registries are configured on a per domain basis rather than a per server basis.
The Certificate Registry is both a CertPath Builder and a CertPath Validator. In either case, the Certificate Registry ensures that the chain’s end certificate is stored in the registry.
A versionable application is an application that has an application archive version specified in the manifest of the application archive (EAR file). Versionable applications can be deployed side-by-side and active simultaneously. Versionable applications allow multiple versions of an application, where security constraints can vary between the application versions.
The Versionable Application provider SSPI enables all security providers that support application versioning to be notified when versions are created and deleted. It also enables all security providers that support application versioning to be notified when non-versioned applications are removed.
The WebLogic Keystore provider uses the reference keystore implementation supplied by Sun Microsystems in the Java Software Development Kit (SDK). It utilizes the standard Java KeyStore (JKS) keystore type, which implements the keystore as a file (one per machine). It protects each private key with its individual password. There are two keystore files associated with the WebLogic Keystore provider:
keytool utility or the WebLogic Server ImportPrivateKey utility to add private keys to this file. Note that WebLogic Server can retrieve private keys and certificates from this keystore file.| Note: | The WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. All of the functionality that was supported by the WebLogic Keystore provider is available through use of Java KeyStores. The WebLogic Keystore provider is only supported for backward compatibility. Oracle recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Securing WebLogic Server. |
The WebLogic Realm Adapter providers provide backward-compatibility with 6.x WebLogic security realms by allowing the use of existing, 6.x security realms with the security features in this release of WebLogic Server. The WebLogic Realm Adapter providers map the realm API (weblogic.security.acl) used in WebLogic Server 6.x to the APIs used in this release of WebLogic Server. The following WebLogic Realm Adapter providers are provided:
The Realm Adapter Authentication provider allows you to use version 6.x security realms and their data stores with the WebLogic security providers in WebLogic Server. The Realm Adapter Authentication provider also allows you to use implementations of the weblogic.security.acl.CertAuthenticator class with WebLogic Server. The Realm Adapter Authentication provider includes a component that provides identity assertion based on X.509 tokens.
In Compatibility security, two types of Authorization providers are used: the WebLogic Authorization provider and the Realm Adapter Authorization provider. The WebLogic Authorization provider is used for new security policies. The Realm Adapter Authorization provider is used for mapping to WebLogic Server 6.1 access control lists (ACLs).
The Realm Adapter Auditing provider allows you to use implementations of the weblogic.security.audit interface with WebLogic Server deployments using Compatibility security.
The Realm Adapter Adjudication provider enables both the WebLogic Authorization provider and the Realm Adapter Authorization provider to be used together for a security realm in Compatibility security.
Although these security providers are configured using the WebLogic Server Administration Console, your existing 6.x security realms will continue to use the same MBeans and user interface present in WebLogic Server 6.1.
| Note: | The WebLogic Realm Adapter providers are deprecated and should only be used while upgrading to the security model available in this release of WebLogic Server. |
|