|
Developing Security Providers for WebLogic Server
|
Introduction to Developing Security Providers for WebLogic Server
The following sections provide an overview of security providers and how they function with the WebLogic Security Framework:
Audience for This Guide
Developing Security Providers for WebLogic Server is designed for independent software vendors (ISVs) who want to write their own security providers for use with WebLogic Server. It is assumed that most ISVs reading this documentation are sophisticated application developers who have a solid understanding of security concepts, and that no basic security concepts require explanation. It is also assumed that security vendors and application developers are familiar with BEA WebLogic Server and with Java (including Java Management eXtensions (JMX)). Prior to reading this guide, readers should review Introduction to WebLogic Security and Terminology.
Security Providers and the WebLogic Security Framework
Security providers are modules that you "plug into" a WebLogic Server security realm to provide security services to applications. You develop a security provider by:
- Implementing the appropriate security service provider interfaces (SSPIs) from the weblogic.security.spi package to create runtime classes for the security provider.
- Creating an MBean Definition File (MDF) and using the WebLogic MBeanMaker utility to generate an MBean type, which is used to configure and manage the security provider.
Security providers call into the WebLogic Security Framework on behalf of applications. The WebLogic Security Framework consists of interfaces, classes, and exceptions in the weblogic.security.service package.
Types of Security Providers
The following sections describe the types of security providers that you can use with WebLogic Server:
Security Provider Summary specifies whether you can configure multiple security providers of the same type in a security realm.
Note: You cannot develop a single security provider that merges several provider types (for example, you cannot have one security provider that does authorization and role mapping).
Authentication Providers
Authentication providers allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Authentication providers that perform: username/password authentication; certificate-based authentication directly with WebLogic Server; and HTTP certificate-based authentication proxied through an external Web server.
Note: An Identity Assertion provider is a special type of Authentication provider that handles perimeter-based authentication and multiple security token types/protocols. For more information, see Identity Assertion Providers.
A LoginModule is the part of an Authentication provider that actually performs the authentication of a user or system. Authentication providers also use Principal Validation providers to verify the authenticity of principals (users/groups) associated with the Java Authentication and Authorization Service (JAAS). For more information about Principal Validation providers, see Principal Validation Providers.
You must have one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm. Having multiple Authentication providers allows you to have multiple LoginModules, each of which may perform a different kind of authentication. An administrator configures each Authentication provider to determine how multiple LoginModules are called when users attempt to login to the system. Because they add security to the principals used in authentication, a Principal Validation provider must be accessible to your Authentication providers.
Authentication providers and LoginModules are discussed in more detail in Authentication Providers.
Identity Assertion Providers
An Identity Assertion provider performs perimeter authentication—a special type of authentication using tokens. Identity Assertion providers also allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Identity Assertion providers that perform perimeter-based authentication (Web server, firewall, VPN) and handle multiple security token types/protocols (SOAP, IIOP-CSIv2).
Identity assertion involves establishing a client's identity using client-supplied tokens that may exist outside of the request. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to principals.
You can develop Identity Assertion providers that support different token types, including Kerberos, SAML (Security Assertion Markup Language) and Microsoft Passport. When used with an Authentication provider's LoginModule, Identity Assertion providers support single sign-on. For example, the Identity Assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.
You can configure multiple Identity Assertion providers in a security realm, but none are required. Identity Assertion providers can support more than one token type, but only one token type per Identity Assertion provider can be active at a given time. For example, an Identity Assertion provider can support both Kerberos and SAML, but an administrator configuring the system must select which token type (Kerberos or SAML) is the active token type for the Identity Assertion provider. If this Identity Assertion provider is set to Kerberos, but SAML token types must be supported, then another Identity Assertion provider that can handle SAML must have SAML set as its active token type.
Identity Assertion providers are discussed in more detail in Identity Assertion Providers.
Principal Validation Providers
Because some LoginModules can be remotely executed on behalf of RMI clients, and because the client application code can retain the authenticated subject between programmatic server invocations, Authentication providers rely on Principal Validation providers to provide additional security protections for the principals contained within the subject.
Principal Validation providers provide these additional security protections by signing and verifying the authenticity of the principals. This principal validation provides an additional level of trust and may reduce the likelihood of malicious principal tampering. Verification of the subject's principals takes place during the WebLogic Server's demarshalling of RMI client requests for each invocation. The authenticity of the subject's principals is also verified when making authorization decisions.
Because you must have one Authentication provider in a security realm, you must also have one Principal Validation provider in a security realm. If you have multiple Authentication providers, each of those Authentication providers must have a corresponding Principal Validation provider.
Principal Validation providers are discussed in more detail in Principal Validation Providers.
Authorization Providers
Authorization providers control access to WebLogic resources based on user identity or other information. The WebLogic security architecture supports several types of authorization:
- Parametric authorization: The parameters to an operation, which are obtained from the application running inside the resource container, are used in making the authorization decision. Thus, parametric authorization allows an authorization decision about a protected WebLogic resource to be determined based on the context of the request.
- Permissions-based authorization: Explicit permissions are given to a user via security policies. Java 2 Enterprise Edition (J2EE) security uses this type of authorization by obtaining data from the weblogic.policy file. Although deprecated in WebLogic Server 7.0, access control lists (ACLs) are an example of permissions-based authorization.
Note: For more information about security policies, see "Understanding WebLogic Security Policies" in Managing WebLogic Security.
- Capabilities-based authorization: Explicit permissions are given to a user (as in permissions-based authorization), but the objects and operations on those objects are also specified. For example, a user can be given permission to access a particular method of an Enterprise JavaBean (EJB). Thus, permissions may be specified at a high or low level. An example of capabilities-based authorization is the use of roles.
An Access Decision is the part of the Authorization provider that actually determines whether a subject has permission to perform a given operation on a WebLogic resource. Authorization providers can also use Principal Validation providers to verify the authenticity of principals (users and groups) associated with the Java Authentication and Authorization Service (JAAS). For more information about Principal Validation providers, see Principal Validation Providers.
You must have one Authorization provider in a security realm, and you can configure multiple Authorization providers in a security realm. Having multiple Authorization providers allows you to follow a more modular design (for example, you may want to have an Authorization provider that handles JNDI permissions and another that handles Web application permissions).
Authorization providers and Access Decisions are discussed in more detail in Authorization Providers.
Adjudication Providers
As part of an Authorization provider, an Access Decision determines whether a subject has permission to access a given WebLogic resource. Therefore, if multiple Authorization providers are configured, each may return a different answer to the "is access allowed?" question. These answers may be PERMIT, DENY, or ABSTAIN. Determining what do to if multiple Authorization providers' Access Decisions do not agree on an answer is the function of an Adjudication provider. The Adjudication provider resolves authorization conflicts by weighing each Access Decision's answer and returning a final result. If you only have one Authorization provider and no Adjudication provider, then an ABSTAIN returned from the single Authorization provider's Access Decision is treated like a DENY.
You must configure an Adjudication provider in a security realm only if you have multiple Authorization providers. You can have only one Adjudication provider in a security realm.
Adjudication providers are discussed in more detail in Adjudication Providers.
Role Mapping Providers
A Role Mapping provider supports dynamic role associations by obtaining a computed set of roles granted to a requestor for a given WebLogic resource. The WebLogic Security Framework determines which roles (if any) apply to a particular subject at the moment that access is required for a given WebLogic resource by:
- Obtaining roles from the J2EE and WebLogic deployment descriptor files.
- Using business logic and the current operation parameters to determine roles.
A Role Mapping provider supplies Authorization providers with this role information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources that use role-based security (that is, Web application and Enterprise JavaBean container resources).
You set roles in J2EE deployment descriptors, or create them using the WebLogic Server Administration Console. These roles are applied at deployment time (unless you specifically choose to ignore the roles).
You must have one Role Mapping provider in a security realm, and you can configure multiple Role Mapping providers in a security realm. Having multiple Role Mapping providers allows you to work within existing infrastructure requirements (for example, configuring one Role Mapping provider for each LDAP server that contains user and role information), or follow a more modular design (for example, configuring one Role Mapping provider that handles mappings for JNDI resources and another that handles mappings for Web applications).
Note: If multiple Role Mapping providers are configured, the set of roles returned by all Role Mapping providers will be intersected by the WebLogic Security Framework. That is, role names from all the Role Mapping providers will be merged into single list, with duplicates removed.
Role Mapping providers are discussed in more detail in Role Mapping Providers.
Auditing Providers
An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. An Auditing provider makes the decision about whether to audit a particular event based on specific audit criteria, including audit severity levels. Auditing providers can write the audit information to output repositories such as an LDAP back-end, database, or simple file. Specific actions, such as paging security personnel, can also be configured as part of an Auditing provider.
Other types of security providers (such as Authentication or Authorization providers) can request audit services before and after security operations have been performed by calling through the Auditor. (The Auditor is the portion of the WebLogic Server Framework that calls into each Auditing provider, enabling audit event recording.)
You can configure multiple Auditing providers in a security realm, but none are required.
Auditing providers are discussed in more detail in Auditing Providers.
Credential Mapping Providers
A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy (or any remote) system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. You can develop a Credential Mapping provider to map credentials in this way.
A Credential Mapping provider can handle several different types of credentials (for example, username/password combinations, Kerberos tickets, and public key certificates). You can set credential mappings in deployment descriptors or by using the WebLogic Server Administration Console. These credential mappings are applied at deploy time (unless you specifically choose to ignore the credential mappings).
You must have one Credential Mapping provider in a security realm, and you can configure multiple Credential Mapping providers in a security realm. If multiple Credential Mapping providers are configured, then the Credential Manager—the portion of the WebLogic Security Framework that calls into each Credential Mapping provider to find out if they contain the type of credentials requested by the container—accumulates and returns all the credentials as a list.
Credential Mapping providers are discussed in more detail in Credential Mapping Providers.
Security Provider Summary
Table 1-1 indicates whether you can configure multiple security providers of the same type in a security realm.
Table 1-1 Security Provider Summary
|
Type
|
Multiple?
|
|
Authentication provider
|
Yes
|
|
Identity Assertion provider
|
Yes
|
|
Principal Validation provider
|
Yes
|
|
Authorization provider
|
Yes
|
|
Adjudication provider
|
No
|
|
Role Mapping provider
|
Yes
|
|
Auditing provider
|
Yes
|
|
Credential Mapping provider
|
Yes
|
Security Providers and Security Realms
All security providers exist within the context of a security realm. If you are not running a prior, 6.x release of WebLogic Server, the WebLogic Server 7.0 security realm defined out-of-the-box as the default realm (that is, the active security realm called myrealm) contains the WebLogic security providers displayed in Figure 1-1.
Note: If you are upgrading from a 6.x release to the 7.0 release, your out-of-the-box experience begins with a compatibility realm—which is initially defined as the default realm—to allow you to work with your existing configuration. Because the 6.x model is deprecated, you need to upgrade your security realm to the 7.0 model. For information about upgrading, see "Upgrading Security" under "Upgrading WebLogic Server 6.x to Version 7.0" in the Upgrade Guide for BEA WebLogic Server 7.0.
Figure 1-1 A WebLogic Server 7.0 Security Realm
Note: The types of security providers that are required for a 7.0 security realm are shown in solid boxes; the security providers that are optional for a 7.0 security realm are shown in dashed boxes.
Because security providers are individual modules or components that are "plugged into" a WebLogic Server security realm, you can add, replace, or remove a security provider with minimal effort. You can use the WebLogic security providers, custom security providers you develop, security providers obtained from third-party security vendors, or a combination of all three to create a fully-functioning security realm. However, as Figure 1-1 also shows, some types of security providers are required for a 7.0 security realm to operate properly. Table 1-2 summarizes which security providers must be configured for a fully-operational 7.0 security realm.
Table 1-2 Security Providers in a Security Realm
|
Type
|
Required?
|
|
Authentication provider
|
Yes
|
|
Identity Assertion provider
|
No
|
|
Principal Validation provider
|
Yes
|
|
Authorization provider
|
Yes
|
|
Adjudication provider
|
Yes, if there are multiple Authorization providers configured.
|
|
Role Mapping provider
|
Yes
|
|
Auditing provider
|
No
|
|
Credential Mapping provider
|
Yes
|
|
Keystore provider
|
No
Note: The WebLogic Keystore provider has been deprecated in WebLogic Server 7.0 SP01, and you cannot develop custom Keystore providers.
|
For more information about security realms, see the following topics in Managing WebLogic Security:
Terminology
The following terms are used in Developing Security Providers for WebLogic Server:
- Access Decision
- Code that determines whether a subject has permission to perform a given operation on a WebLogic resource, with specific parameters in an application. The result of an Access Decision is to permit, deny, or abstain from making a decision. An Access Decision is a component of an Authorization provider. See also subject, WebLogic resource.
- Adjudicator
- Code that resolves conflicts between multiple Access Decisions, by tallying each Access Decision and returning a final result. See also Access Decision.
- auditing
- Process whereby information about operating requests and the outcome of those requests is collected, stored, and distributed for the purposes of non-repudiation. Auditing provides an electronic trail of computer activity.
- authentication
- Process whereby the identity of users or system processes are proved or verified. Authentication also involves remembering, transporting, and making identity information available to various components of a system when that information is needed. Authentication is typically done using username/password combinations, but may also be done using tokens. See also LoginModule, identity assertion, perimeter authentication.
- authorization
- Process whereby the interactions between users and WebLogic resources are limited to ensure integrity, confidentiality, and availability. Authorization controls access to resources based on user identity or other information. See also parametric authorization, WebLogic resource.
- certificate
- Digital statement that associates a particular public key with a name or other attributes. The statement is digitally signed by a certificate authority (CA). By trusting that authority to sign only true statements, you can trust that the public key belongs to the person named in the certificate. See also public key, trusted (root) CA.
- compatibility realm
- Security realm that is the default realm if you are running a prior, 6.x release of WebLogic Server. The compatibility realm uses your existing providers and allows you to migrate to the new security architecture. If WebLogic Server does not find an existing provider for a particular security service, the appropriate WebLogic security provider will be configured in the compatibility realm. See also default realm, security realm, WebLogic security provider.
- credential
- Security-related attribute of a subject, which may contain information used to authenticate the subject to new services. Types of credentials include username/password combinations, Kerberos tickets, and public key certificates. See also credential map.
- credential map
- Mapping of credentials used by WebLogic Server to credentials used in a legacy or any remote system, thereby telling WebLogic Server how to connect to a given resource in that system. See also credential.
- custom security provider
- Security provider written by a third-party security vendor or security application developer that does not come with WebLogic Server. See also security provider, WebLogic security provider.
- database delegator
- Intermediary class that mediates initialization calls between a security provider and the security provider's database. See also security provider database.
- default realm
- Active security realm in which the WebLogic security providers are already configured, if you are running WebLogic Server 7.0. See also compatibility realm, security realm.
- domain
- A collection of servers, services, interfaces, machines, and associated WebLogic resource managers defined by a single configuration file. See also WebLogic resource.
- dynamic role association
- Late binding of principals to roles at runtime, which occurs just prior to an authorization decision for a protected WebLogic resource. See also authorization, principal, role, WebLogic resource.
- group
- Set of users that share some characteristics. Giving permission to a group is the same as giving the permission to each user who is a member of the group. See also user.
- identity assertion
- Special type of authentication whereby a client's identity is established through the use of client-supplied tokens that may exist outside of the request. Identity is asserted when tokens are mapped to usernames. Identity assertion can be used to enable single sign-on. See also authentication, single sign-on, token.
- Java Authentication and Authorization Service (JAAS)
- Set of packages that enable services to authenticate and enforce access controls upon users. It implements a Java version of the standard Pluggable Authentication Module (PAM) framework, and supports user-based authorization. See also authentication.
- LoginModule
- Code based on the Java Authentication and Authorization Service (JAAS) that is responsible for authenticating users within the security realm and for populating a subject with the necessary principals. A LoginModule is a component of Authentication and Identity Assertion providers. See also authentication.
- MBean
- Short for "managed bean," a Java object that represents a Java Management eXtensions (JMX) manageable resource. MBeans are instances of MBean types. MBeans are used to configure and manage your security providers. See also MBean type, security provider.
- MBean Definition File (MDF)
- XML file used by the WebLogic MBeanMaker to generate files for an MBean type. See also MBean type, WebLogic MBeanMaker.
- MBean implementation file
- One of several intermediate Java files generated by the WebLogic MBeanMaker utility to create an MBean type for a custom security provider. You edit this file to supply your specific method implementations. See also MBean information file, MBean interface file, MBean type, WebLogic MBeanMaker.
- MBean information file
- One of several intermediate Java files generated by the WebLogic MBeanMaker utility to create an MBean type for a custom security provider. This file contains mostly metadata and therefore requires no editing. See also MBean implementation file, MBean interface file, MBean type, WebLogic MBeanMaker.
- MBean interface file
- One of several intermediate Java files generated by the WebLogic MBeanMaker utility to create an MBean type for a custom security provider. This file is the client-side API to the MBean that your runtime class or your MBean implementation will use to obtain configuration data, and requires no editing. See also MBean implementation file, MBean information file, MBean type, runtime class, WebLogic MBeanMaker.
- MBean JAR File (MJF)
- JAR file that contains the runtime classes and MBean types for a security provider. MJFs are created by the WebLogic MBeanMaker and are installed into WebLogic Server. See also MBean type, runtime class, security provider, WebLogic MBeanMaker.
- MBean type
- Factory for creating the MBeans used to configure and manage security providers. MBean types are created by the WebLogic MBeanMaker. See also MBean, security provider, WebLogic MBeanMaker.
- parametric authorization
- The ability to perform authorization decisions on protected WebLogic resources, taking the context and target of the business request into account. See also authorization, WebLogic resource.
- perimeter authentication
- Special type of authentication whereby tokens are used instead of a username/password combination. Perimeter authentication is made possible through identity assertion. See also authentication, identity assertion.
- principal
- The identity assigned to a user or system process as a result of authentication. A principal can consist of any number of users and groups. Principals are typically stored within subjects. See also authentication, group, subject, user.
- principal validation
- The act of signing and later verifying that a principal has not been altered since it was signed. Principal validation establishes trust of principals. See also principal.
- private key
- An encryption/decryption key known only to the party or parties that exchange secret messages. See also public key.
- public key
- Value provided by some designated authority as an encryption key that, combined with a private key derived from the public key, can be used to effectively encrypt messages and digital signatures. See also private key.
- resource adapter
- System-level software driver used by an application server such as WebLogic Server to connect to an enterprise information system (EIS).
- role
- Abstract, logical collections of users similar to a group. The difference between groups and roles is a group is a static identity that a system administrator assigns, while membership in a role is dynamically calculated based on data such as username, group membership, or the time of day. Roles are granted to individual users or to groups, and multiple roles can be used to create security policies for a WebLogic resource. See also dynamic role association, group, security policy, user, WebLogic resource.
- role mapping
- Process whereby the groups and/or principals recognized by the container are associated with the security roles specified in a deployment descriptor. See also group, principal, role.
- runtime class
- Java class that implements the security service provider interfaces (SSPIs) and contains the actual security-related behavior for a security provider. See also security provider, security service provider interface (SSPI).
- security policy
- An association between a WebLogic resource and a user, group, or role that is designed to protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you assign it a security policy. You assign security policies to an individual WebLogic resource or to attributes or operations of the WebLogic resource. See also group, role, user, WebLogic resource.
- security provider
- Modules that can be "plugged into" a WebLogic Server security realm to provide security services (such as authentication, authorization, auditing, or PKI) to applications. A security provider consists of runtime classes and MBeans, which are created from SSPIs and MBean types, respectively. Security providers may be categorized as WebLogic security providers and custom security providers. See also custom security provider, security service provider interface (SSPI), MBean, MBean type, runtime class, WebLogic security provider.
- security provider database
- Database that contains the users, groups, policies, roles, and credentials used by some types of security providers to provide security services. The security provider database can be the embedded LDAP server (as used by the WebLogic security providers), a properties file (as used by the sample security providers), or a production-quality database that you may already be using.
- security realm
- Container for the mechanisms—including authenticators, adjudicators, authorizers, auditors, role mappers, and credential mappers—that are used to protect WebLogic resources. All security providers exist within the context of a security realm. You can have multiple security realms in a domain, but only one can be the active (default) realm. See also compatibility realm, default realm, domain, security provider, WebLogic resource.
- security service provider interface (SSPI)
- Interfaces used by BEA to create runtime classes for the WebLogic security providers, and from which you create runtime classes for custom security providers. See also runtime class, security provider.
- single sign-on
- Ability to require a user to sign on to an application only once and gain access to many different application components, even though these components may have their own authentication schemes. Single sign-on is acheived using identity assertion, LoginModules, and tokens. See also authentication, identity assertion, LoginModule, token.
- SSPI MBean
- Interfaces used by BEA to generate MBean types for the WebLogic security providers, and from which you generate MBean types for custom security providers. SSPI MBeans may be required (for configuration) or optional (for management). See also MBean type, security provider.
- subject
- Container for authentication information, including principals, as specified by the Java Authentication and Authorization Service (JAAS). You can store any number of principals in a subject. See also authentication, Java Authentication and Authorization Service (JAAS), principal.
- token
- Artifact resulting from the authentication process that must be presented to determine information about the authenticated user at a later time. Tokens come in many different formats or types, including Kerberos and SAML. See also authentication, identity assertion, single sign-on, user.
- trusted (root) CA
- Special type of certificate issued by a trusted certificate authority (CA). A trusted CA also contains a public key, so it can be paired with a private key. See also private key, public key.
- user
- Entities that use WebLogic Server, such as application end users, client applications, and other instances of WebLogic Server. Users may be placed into groups that are associated with roles, or be directly associated with roles. See also group, role.
- WebLogic MBeanMaker
- Command-line utility that takes an MBean Definition File (MDF) as input and outputs files for an MBean type. See also MBean Definition File (MDF), MBean type.
- WebLogic resource
- Entities that are accessible from WebLogic Server, such as events, servlets, JDBC connection pools, JMS destinations, JNDI contexts, connections, sockets, files, and enterprise applications and resources, such as databases.
- WebLogic Security Framework
- Interfaces in the weblogic.security.service package that unify security enforcement and present security as a service to other WebLogic Server components. Security providers call into the WebLogic Security Framework on behalf of applications requiring security services.
- WebLogic security provider
- Security provider supplied by BEA Systems as part of WebLogic Server. See also custom security provider, security provider.
