Introduction to WebLogic Security
In WebLogic 6.x, a data structure used to control access to computer resources. Each entry on the access control list (ACL) contains a set of permissions associated with a particular principal that represents an individual user or a group of users. Entries can be positive or negative. An entry is positive if it grants permission and negative if it denies permission. In WebLogic Server 7.0 and later, ACLs are deprecated and are replaced by security policies. To continue to protect WebLogic resources with ACLs, use Compatibility security. See also Compatibility security, group, principal, security policy, user, WebLogic resource.
Code that determines whether a subject has permission to perform a given operation on a WebLogic resource. 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 Authorization provider, subject, WebLogic resource.
A WebLogic security provider that tallies the results that multiple Access Decisions return, resolves conflicts between the Access Decisions, and determines the final
DENY decision. The Adjudicator is a component of the Adjudication provider. See also Access Decision, security provider.
A key-based cryptography that uses an encryption algorithm in which different keys, private and public, are used to encrypt and decrypt the data. Data that is encrypted with the public key can be decrypted only with the private key. This asymmetry is the property that makes public key cryptography so useful. Asymmetric key cryptography is also called public key cryptography. See also private key, public key, symmetric key cryptography.
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. See also Auditing provider.
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 typically involves username/password combinations, but can also be done using tokens. See also Authentication provider, Identity Assertion, LoginModule, perimeter authentication, token, user.
A security provider that enables WebLogic Server to establish trust by validating a user. The WebLogic Security Service 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. See also authentication, digital certificate, security provider, user.
Process whereby a user's access to a WebLogic resource is permitted or denied based on the user's security role and the security policy assigned to the requested WebLogic resource. See also Authorization provider, security policy, user, WebLogic resource.
A security provider that controls access to WebLogic resources based on the user's security role and the security policy assigned to the requested WebLogic resource. See also security provider, user, WebLogic resource.
A WebLogic Server 6.x feature that applies to WebLogic Server 7.0 and later only if you use Compatibility security. A Caching realm is a temporary location in memory that contains frequently called ACLs, users, groups, and so on, from the primary realm. In WebLogic Server 6.x, users, groups, and ACL objects are stored in the
filerealm.properties file, and reading from a file can be very slow. The Caching realm is a communication layer on top of the primary realm and is used for lookups, by default. If the Caching realm lookup fails, a lookup is performed on the primary realm. See also access control list (ACL), Compatibility security, group, user.
See digital certificate.
Method of providing a confident identification of a client by a server through the use of digital certificates. Certificate authentication is generally preferred over password authentication because it is based on what the user has (a private key), as well as what the user knows (a password that protects the private key). See also authentication, certificate authority, certificate.
A trusted entity that issues public key certificates. A certificate authority attests to a user's real-world identity, much as a notary public does. See also certificate chain, digital certificate, entity, private key, public key, trusted (root) certificate authority.
An array that contains a private key, the matching public key, and a chain of digital certificates for trusted certificate authorities, each of which is the issuer of the previous digital certificate. The certificate for the server, authority, authority2, and authority3, constitute a chain, where the server certificate is signed by the authority, the authority's certificate is signed by authority2, and authority2's certificate is signed by authority3. If the certificate authority for any of these authorities is recognized by the client, the client authenticates the server. See also trusted (root) certificate authority.
Security realm that is the default (active) security realm if you are using Compatibility security. The Compatibility realm adapts your existing WebLogic Server 6.x Authentication and Authorization providers so that you can use them in WebLogic Server 7.x or later. The only security realm available in Compatibility security is the Compatibility realm. See also Compatibility security, default realm, security provider, security realm, WebLogic security provider.
The capability to run security configurations from WebLogic Server 6.x in later releases of WebLogic Server. Using Compatibility security in WebLogic Server 7.x or later, you configure 6.x security realms; define users, groups, and ACLs; manage protection of user accounts; and install custom auditing providers. The only security realm available in Compatibility security is the Compatibility realm. The Realm Adapter providers in the Compatibility realm allow backward compatibility to the authentication and authorization services in 6.x security realms. See also access control list (ACL), Auditing provider, Compatibility realm, group, Realm Adapter Authentication provider, Realm Adapter Authorization provider, security realm, user.
A programmable filter that WebLogic Server uses to determine whether the server should allow incoming connections from a network client. In addition to security policies that protect WebLogic resources based on user characteristics, you can add another layer of security by filtering based on network connections. See also security policy, user, WebLogic resource.
See resource adapter
A ContextHandler is a high-performing WebLogic class that obtains additional context and container-specific information from the resource container, and provides that information to security providers making access or role mapping decisions. The
ContextHandler interface provides a way for an internal WebLogic resource container to pass additional information to a WebLogic Security Framework call, so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular method. A ContextHandler is essentially a name/value list, and as such, it requires that a security provider know what names to look for. (In other words, use of a ContextHandler requires close cooperation between the WebLogic resource container and the security provider.) See also security provider, WebLogic container, WebLogic Security Framework.
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 mapping, Credential Mapping provider, digital certificate, Kerberos ticket, public key, subject.
The process whereby a legacy system's database is used to obtain an appropriate set of credentials to authenticate users to a target resource. WebLogic Server uses credential mapping to map credentials used by WebLogic Server users to credentials used in a legacy (or any remote) system. WebLogic Server then uses the credential maps to log in to a remote system on behalf of a subject that has already been authenticated. See also credential, Credential Mapping provider, resource.
A security provider that is used to provide credential mapping services and bring new types of credentials into the WebLogic Server environment. See also credential, credential mapping, security provider.
WebLogic Server security feature that allows users to authenticate once but access multiple applications, even if these applications reside in different DNS domains. You can use this feature to construct a network of affiliates or partners that participate in a Single Sign-On domain. See also single sign-on (SSO).
Note: Cross-domain single sign-on is only supported for Java clients, that is, clients that are running a Java Virtual Machine (JVM); Cross-domain single sign-on is not supported with Web browser clients.
A protocol that is based on IIOP (GIOP 1.2) and the CORBA Common Secure Interoperability version 2 (CSIv2) CORBA specification. The secure interoperability requirements for EJB2.0 and other J2EE1.4.1 containers correspond to Conformance Level 0 of the CSIv2 specification. The CORBA Security Attribute Service (SAS) is the protocol that is used in CSIv2. For more information, see http://www.omg.org/technology/documents/formal/omg_security.htm.
Security provider written by third-party security vendors or security developers that can be integrated into the WebLogic Security Service. Custom security providers are implementations of the Security Service Provider Interfaces (SSPIs) and are not supplied with the WebLogic Server product. See also security provider, security realm, WebLogic security provider, WebLogic Security Service.
In WebLogic Server 7.0 and later, supported only in Compatibility security. In WebLogic Sever 6.x, you customize authentication by creating your own security realm and integrating it into the WebLogic Server environment. See also Compatibility security.
Intermediary class that mediates initialization calls between a security provider and the security provider's database. See also security provider database.
Security that is defined, or declared, using the application deployment descriptors. For Web applications, you define the deployment descriptors in the
weblogic.xml files. For EJBs, you define the deployment descriptors in the
The active security realm. In WebLogic Server 7.0 and later, you can configure multiple security realms in a WebLogic Server domain; however, only one can be the default (active) security realm. See also Custom security realm, security realm,WebLogic Server domain.
Digital statement that associates a particular public key with a name or other attributes. The statement is digitally signed by a certificate authority. 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 certificate authority, digital signature, public key, trusted (root) certificate authority.
String of bits used to protect the security of data being exchanged between two entities by verifying the identities of those entities. Specifically, this string is used to verify that the data came from the sending entity of record and was not modified in transit. A digital signature is computed from an entity's signed data and private key. It can be trusted only to the extent that the public key used to verify it can be trusted. See also entity, private key, public key.
An interactive, graphical user interface (GUI) that facilitates the creation of a new WebLogic Server domain. The wizard can create WebLogic Server domain configurations for stand-alone servers, Administration Servers with Node Managers and Managed Servers, and clustered servers. You can use it to create the appropriate directory structure for your WebLogic Server domain, a basic
config.xml file, and scripts that you can use to start the servers in your domain.
A server that contains user, group, security role, security policy and credential information. The WebLogic Authentication, Authorization, Role Mapping, and Credential Mapping providers use the embedded LDAP server as their security provider databases. See also credential, group, security policy, security role.
In WebLogic Server 6.x, a realm that stores users, groups, encrypted passwords, and ACLs in a file. In WebLogic Server 7.0 and later you use a File realm only with Compatibility security. See also Compatibility security.
Software that monitors traffic between an internal network and the Internet, and that regulates the type of network traffic that can enter and leave the internal network. A firewall can be connected to the Internet or set up within a company's network to prevent unauthorized access to the network. Firewalls protect information on computers and information that is being carried over the network. Firewalls use various types of filters to prevent access, including limiting the types of protocols allowed and restricting access from network nodes by IP addresses and DNS node names.
Collection of users that share some characteristic, such as a department, a job function, or a job title. Groups are a static identity that a server administrator assigns. Groups are associated with security roles. 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.
Code that validates that the host to which an SSL connection is made is the intended or authorized party. A Host Name Verifier is useful when a WebLogic Server client or a WebLogic Server instance acts as an SSL client to another application server. It helps prevent man-in-the-middle attacks. By default, WebLogic Server, as a function of the SSL handshake, compares the common name in the subject distinguished name (DN) of the SSL server's digital certificate with the host name of the SSL server used to initiate the SSL connection. If the subject DN and the host name do not match, the SSL connection is dropped. See also digital certificate, host name verification, Secure Sockets Layer (SSL), subject.
Special type of authentication whereby a client's identity is established through the use of client-supplied tokens that are generated from an outside source. Identity is asserted when these tokens are mapped to usernames. For example, the client's identity can be established by using a digital certificate, and that certificate can be passed around the system so that users are not asked to sign on more than once. Thus, identity assertion can be used to enable single sign-on. See also authentication, digital certificate, Identity Assertion provider, single sign-on (SSO), SSL tunneling, token.
A security provider that performs perimeter authentication—a special type of authentication using tokens. Identity Assertion providers also allow WebLogic Server to establish trust by validating a user. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. See also perimeter authentication, security provider, token, user.
If a security realm has multiple Authentication providers configured, the JAAS control flag determines how the login sequence uses the Authentication providers. See also Authentication provider.
Responsible for authenticating users within the security realm and for populating a subject with the necessary principals (users/groups). A LoginModule is a required component of an Authentication provider, and can be a component of an Identity Assertion provider if you want to develop a separate LoginModule for perimeter authentication. LoginModules that are not used for perimeter authentication also verify the proof material submitted (for example, a user's password). See also authentication, group, Identity Assertion provider, perimeter authentication, principal, security realm, subject.
Set of Java packages that enable services to authenticate and enforce access controls upon users. JAAS implements a Java version of the standard Pluggable Authentication Module (PAM) framework, and supports user-based authorization. WebLogic Server only implements the authentication portion of JAAS. See also authentication, authorization, user.
A framework for accessing and developing cryptographic functionality for the Java platform. For a description of the Java Cryptography Architecture provided by Sun Microsystems, Inc., see http://java.sun.com/j2se/1.4/docs/guide/security/CryptoSpec.html#Introduction. See also Java Cryptography Extensions (JCE)
Set of Java packages that extends the Java Cryptography Architecture API to include APIs for encryption, key exchange, and Message Authentication Code (MAC) algorithms. See http://java.sun.com/j2se/1.4/docs/guide/security/jce/
JCERefGuide.html for a description of JCE provided by Sun Microsystems, Inc. See also Java Cryptography Architecture.
The Java Naming and Directory Interface (JNDI) is an application programming interface (API) that provides naming services to Java applications. JNDI is an integral component of the Sun Microsystems J2EE technology and is defined to be independent of any specific naming or directory service implementation. It supports the use of a single method for accessing various new and existing services. This support allows any service-provider implementation to be plugged into the JNDI framework using the standard service provider interface (SPI) conventions. In addition, JNDI allows Java applications in WebLogic Server to access external directory services such as LDAP in a standardized fashion, by plugging in the appropriate service provider.
Security manager for the Java virtual machine (JVM). The Java Security Manager works with the Java API to define security boundaries through the
java.lang.SecurityManager class, thus, enabling developers to establish a custom security policy for their Java applications.
WebLogic Server supports the use of the Java Security Manager to prevent untrusted code from performing actions that are restricted by the Java security policy file. The Java Security Manager uses the Java security policy file to enforce a set of permissions granted to classes. The permissions allow specified classes running in that instance of the JVM to permit or deny certain runtime operations. See also Java security policy file, policy condition.
File used by the Java Security Manager to enforce a set of permissions granted to specified classes running in an instance of the WebLogic Server-supported Java Virtual Machine (JVM). Classes running in that instance of the JVM use the permissions to permit or deny certain runtime operations. See also Java Security Manager, policy condition.
A sequence of a few hundred bytes in length that is used to control access to physically insecure networks. Kerberos tickets are based on the Kerberos protocol. Kerberos is a network authentication protocol that allows entities (users and services) communicating over networks to prove their identity to each other, while preventing eavesdropping or replay attacks. The protocol was designed to provide strong authentication for client/server applications by using secret-key cryptography. For more information, see http://web.mit.edu/kerberos/www/. See also private key.
An in-memory collection of private key and trusted certificate pairs. The information is protected by a passphrase, such as a password, a credit card number, Personal Identification Number, or some other form of personal identification information. In the Administration Console, the keystore is referred to as the Trusted Keystore. For more information, see SDK 1.4.1 Javadoc produced by Sun Microsystems, Inc., which is available at http://java.sun.com/j2se/1.4/docs/api/index.html. See also private key, trusted (root) certificate authority.
Authentication provider that uses a Lightweight Data Access Protocol (LDAP) server to access user and group information, for example, iPlanet's Active Directory and Novell's OpenLDAP. See also group, user.
A WebLogic Server 6.x security realm. In WebLogic Server 6.x, security realms provide authentication and authorization services. The LDAP security realm provides authentication through an LDAP server. This server allows you to manage all the users for your organization in one place: the LDAP directory. The LDAP security realm supports Open LDAP, Netscape iPlanet, Microsoft Site Server, and Novell NDS. In WebLogic Server 7.x or later, you can only use the LDAP security realm when using Compatibility security. See also authentication, authorization, Compatibility security, File realm, security realm, user.
See JAAS LoginModule.
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 security providers. See also MBean type, security provider.
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.
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.
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.
JAR file that contains the runtime classes and MBean types for a security provider. MJFs are created by the WebLogic MBeanMaker. See also MBean type, runtime class, security provider, WebLogic MBeanMaker.
A digitally created hash, or fingerprint, created from a block of plain text. Even though the complete message is used to create the hash, the message cannot be recreated from the hash. Message digests help prevent man-in-the-middle attacks. Because there is only one digest for any given block of plain text, the digest can be used to verify the authenticity of the message. Thus, this process results in a digital signature of the message, which can be used to provide non-repudiation and integrity services. See also message digest algorithm.
A computational procedure that is used to produce a message digest from a block of plain text. Once a message digest is produced, other security mechanisms are used to encrypt and convey the digest. See also message digest.
Authentication that requires both client and server to present proof of identity. Two-way SSL authentication is a form of mutual authentication in that both client and server present digital certificates to prove their identity. However, with two-way SSL, the authentication happens at the SSL level, whereas other forms of mutual authentication are executed at higher levels in the protocol stack. See also authentication, digital certificate, Secure Sockets Layer (SSL), two-way SSL authentication, trusted (root) certificate authority.
Identity Assertion provider that decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic uses for the purpose of single sign-on. See also Simple and Protected Negotiation Mechanism (SPNEGO) and single sign-on (SSO) with Desktop clients.
Type of SSL authentication which requires the server to present a certificate to the client, but the client is not required to present a certificate to the server. The client must authenticate the server, but the server will accept any client into the connection. Enabled by default in WebLogic Server. See also mutual authentication, two-way SSL authentication.
Authentication that occurs outside the application server domain. Perimeter authentication is typically accomplished when a remote user specifies an asserted identity and some form of corresponding proof material, normally in the form of a passphrase (such as a password, a credit card number, Personal Identification Number, or some other form of personal identification information.), to an authentication server (typically a Web server) that performs the verification and then passes an artifact, or token, to the application server domain (for example, a WebLogic Server domain). The application server can then pass the token around to systems in the domain so that users are not asked to sign on more than once.
The authentication agent, the entity that actually vouches for the identity, can take many forms, such as a Virtual Private Network (VPN), a firewall, an enterprise authentication service (Web server), or some other form of global identity service.
The WebLogic Server security architecture supports Identity Assertion providers that perform perimeter authentication (Web server, firewall, VPN) and handle multiple security token types and protocols (SOAP, IIOP-CSIv2). See also authentication, Identity Assertion.
A condition under which a security policy will be created. Policy conditions, along with the specific information you supply for the condition (such as an actual user name, group, security role, or start/stop times), are called expressions. See also policy statement.
See policy statement.
A policy statement is the collection of expressions that define who is granted access to a WebLogic resource, and is therefore the main part of any security policy you create. Policy statements are also referred to as policy expressions. See also policy condition.
The identity assigned to a user, group, 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.
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.
An encryption/decryption key known only to the party or parties that exchange secret messages. It is called private because it must be kept secret from everyone but the owner. See also public key.
The computational procedure used to encode, or encrypt, ciphertext. Data encrypted with the private key can only be decrypted by the public key. See also private key, public key, RDBMS security realm.
Value provided by a certificate authority as an encryption/decryption key that, combined with a private key, can be used to effectively encrypt and decrypt messages and digital signatures. The key is called public because it can be made available to anyone. Public key cryptography is also called asymmetric cryptography because different keys are used to encrypt and decrypt the data. See also asymmetric key cryptography, private key.
The computational procedure used to encode, or encrypt, plain text. Data encrypted with the public key can only be decrypted by the private key. See also private key, private key algorithm, public key.
A WebLogic Server 6.x security realm. In WebLogic Server 6.x, security realms provided authentication and authorization services. The RDBMS security realm stores Users, Groups, and ACLs in a relational database. In WebLogic Server 7.0 and later, you can only use the RDMS security realm when using Compatibility security. See also access control list (ACL), authentication, authorization, Compatibility security, group, security realm, user.
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. See also Compatibility security, Compatibility realm.
Auditing provider in the CompatibilityRealm that allows you to use implementations of the
weblogic.security.audit interface with WebLogic Server deployments using Compatibility security. You must run Compatibility security in order to access the Compatibility realm and the Realm Adapter providers through the WebLogic Server Administration Console. See also Compatibility security, Compatibility realm.
Authentication provider in the Compatibility realm that allows backward compatibility to the authentication services in 6.x security realms. You must run Compatibility security in order to access the Compatibility realm and the Realm Adapter providers through the WebLogic Server Administration Console. See also Compatibility security, Compatibility realm.
Authorization provider in the Compatibility realm that allows backward compatibility to the authorization services in 6.x security realms. You must run Compatibility security in order to access the Compatibility realm and the Realm Adapter providers through the WebLogic Server Administration Console. See also Compatibility security, Compatibility realm.
Type of security provider used to access WebLogic Server 6.x security services when using Compatibility security in WebLogic Server 7.0 or later. These providers allow you to adapt 6.x security providers so that they can be used with WebLogic Server 7.0 and later. You must run Compatibility security in order to access the Compatibility realm and the Realm Adapter providers through the WebLogic Server Administration Console. See also Compatibility security, Compatibility realm.
See WebLogic resource.
System-level software driver (also called a connector) used by an application server (such as WebLogic Server) or an application client to connect to an enterprise information system (EIS). Resource adapters contain the Java components and, if necessary, the native components required to interact with the EIS.
The WebLogic J2EE Connector Architecture supports resource adapters developed by EIS vendors and third-party application developers that can be deployed in any application server supporting the Sun Microsystems J2EE Platform Specification, version 1.3.
A condition under which a security role (global or scoped) will be granted to a user or group. Role conditions, along with the specific information you supply when creating the condition (such as an actual user name, group, or start/stop times), are called expressions. See security policy, role mapping.
Specific information that you supply when creating role conditions. See role condition.
Process by which the WebLogic Security Service compares users or groups against a security role condition to determine whether they should be dynamically granted a security role. Role mapping occurs at runtime, just prior to when an Access Decision is rendered for a protected WebLogic resource. See also Access Decision, group, principal, role condition, security role, user, WebLogic resource, WebLogic Security Service.
A security provider that determines what security roles apply to the principals stored in a subject when the subject is attempting to perform an operation on a WebLogic resource. Because this operation usually involves gaining access to the WebLogic resource, Role Mapping providers are typically used with Authorization providers. See also Authorization provider, principal, security role, subject, WebLogic resource.
A collection of expressions that define how a security role is granted, and is therefore the main part of any security role you create. See role expression.
Java class that implements a Security Service Provider Interface (SSPI) and contains the actual security-related behavior for a security provider. See also security provider, Security Service Provider Interfaces (SSPIs).
An Internet transport-level technology developed by Netscape to provide data privacy between applications. Generally, Secure Sockets Layer (SSL) provides (1) a mechanism that the applications can use to authenticate each other's identity and (2) encryption of the data exchanged by the applications. SSL supports the use of public key cryptography for authentication, and secret key cryptography and digital signatures to provide privacy and data integrity. See also authentication, digital signature, public key cryptography, symmetric key cryptography.
An XML-based framework for exchanging security information. SAML implementations provide an interoperable, XML-based, security solution that allows authentication and authorization information to be exchanged securely. SAML is the key to enabling single sign-on capabilities for Web services. For more information, see http://xml.coverpages.org/saml.html.
You can develop custom Identity Assertion providers for WebLogic Server that support different token types, including SAML. See also authentication, authorization, Identity Assertion, perimeter authentication, Cross-Domain Single Sign-on, user.
An association between a WebLogic resource and a user, group, or security role that protects the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you assign it a security policy. You can assign security policies to an individual WebLogic resource or to components of the WebLogic resource.
In WebLogic Server 7.0 and later, security policies replace access control lists (ACLs), except when Compatibility security is used. See also access control list (ACL), group, security role, user, WebLogic resource.
In WebLogic Server 7.0 and later, software modules that can be "plugged into" a WebLogic Server security realm to provide security services (such as authentication, authorization, auditing, and credential mapping) to applications. A security provider consists of runtime classes and MBeans, which are created from SSPIs and MBean types, respectively. Security providers are WebLogic security providers (provided with WebLogic Server) or custom security providers. See also custom security provider, MBean, MBean type, runtime class, Security Service Provider Interfaces (SSPIs), WebLogic security provider.
Database that contains the users, groups, security 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. See also credential, embedded LDAP server, group, security role, security policy, WebLogic security provider.
In WebLogic Server 6.x, security realms provide authentication and authorization services. You use the File realm or a set of alternative security realms, including the Lightweight Data Access Protocol (LDAP), Windows NT, Unix, or RDBMS realms. If you want to customize authentication, you write your own security realm and integrate it into the WebLogic Server environment. In WebLogic Server 6.x you cannot have multiple security realms in a domain. See also File realm.
In WebLogic Server 7.0 and later, security realms act as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, roles, and security policies. You can configure multiple security realms in a domain; however, only one can be the default (active) security realm. WebLogic Server provides two default security realms: myrealm and Compatibility realm. You can access an existing 6.x security configuration through the Compatibility realm. You can no longer write a custom security realm using the application programming interfaces as you could in WebLogic Server 6.x; rather, you configure a new security realm (called myrealm by default) to provide the security services you want and then set the new security realm as the default security realm. See also Compatibility realm, Custom security realm, default realm, Domain Configuration Wizard, security provider, WebLogic resource.
A dynamically computed privilege that is granted to users or groups based on specific conditions. The difference between groups and roles is that a group is a static identity that a server administrator assigns, while membership in a role is dynamically calculated based on data such as user name, group membership, or the time of day. Security roles are granted to individual users or to groups, and multiple roles can be used to create security policies for a WebLogic resource. Once you create a security role, you define an association between the role and a WebLogic resource. This association (called a security policy) specifies who has what access to the WebLogic resource. See also global role, group, role mapping, scoped role, security policy, user, WebLogic resource.
Set of WebLogic packages that enables custom security providers to be developed and integrated with the WebLogic Server Security Service. These interfaces are implemented by the WebLogic security providers and custom security providers. The WebLogic Security Framework calls methods in these interfaces to perform security operations. See also security provider, WebLogic Security Framework.
Allows participation in a Kerberos-based Single Sign-On (SSO) environment. The SPNEGO protocol performs a Kerberos authentication via HTTP, and allows Internet Explorer to pass a delegated credential to allow a web application to log in to subsequent Kerberized services on the user's behalf. See also Negotiate Identity Assertion provider, single sign-on (SSO) with Desktop clients.
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 achieved using identity assertion, LoginModules, and tokens. See also authentication, Cross-Domain Single Sign-on, Identity Assertion, JAAS LoginModule, token, user.
Ability of desktop clients that have authenticated in the Windows Active Directory enviroment to access a Web application running on WebLogic Server and use their Windows Active Directory credentials to authenticate to the server.
SSO with desktop clients is achieved by usig the Negotiate Identity Assertion provider. The provider decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. See also Negotiate Identity Assertion provider and Simple and Protected Negotiation Mechanism (SPNEGO).
A peripheral Secure Sockets Layer (SSL) platform that attaches to a Web switch with the express purpose of improving SSL performance for a client. For example, the Alteon SSL Accelerator can be used with WebLogic Server. This accelerator performs a TCP handshake with the client (in this case, WebLogic Server) through a Web switch and performs all the SSL encryption and decryption for the session.
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 custom security provider, MBean type, WebLogic security provider.
A grouping of related information for a single entity, such as a person, as specified by the Java Authentication and Authorization Service (JAAS). The related information includes the Subject's identities, or Principals, as well as its security-related attributes (for example, passwords and cryptographic keys). A subject can contain any number of Principals. Both users and groups can be used as Principals by application servers such as WebLogic Server. In WebLogic security providers (security providers supplied with the WebLogic Server product), the Subject contains a Principal for the user (
WLSUser Principal) and a Principal for each group of which the user is a member (
WLSGroups Principals). Custom security providers may store identities differently. See also authentication, custom security provider, group, JAAS control flag, principal, user.
A key-based cryptography that uses an encryption algorithm in which the same key is used both to encrypt and decrypt the data. Symmetric key cryptography is also called secret key cryptography. See also asymmetric key cryptography.
Artifact generated as part of the authentication process of users or system processes. When using Identify Assertion, a token is presented to show that the user has been authenticated. Tokens come in many different types, including Kerberos and Security Assertion Markup Language (SAML). See also authentication, Security Assertion Markup Language (SAML), Secure Sockets Layer (SSL), Identity Assertion, SSL tunneling, Security Assertion Markup Language (SAML), user.
An interface that enables you to override validation errors in a peer's digital certificate and continue the SSL handshake. You can also use the interface to discontinue an SSL handshake by performing additional validation on a server's digital certificate chain.
A well-known and trusted third-party organization or company that issues digital certificates used to create digital signatures and public-private key pairs. The function of the trusted certificate authority is similar to that of a notary public: to guarantee the identify of the individual or organization presenting the certificate. Trusted certificate authorities issue certificates that are used to sign other certificates. Certificate authorities are referred to as root certificate authorities because their authority is recognized and thus they do not need anyone to validate their identity. Trusted (root) certificate authority (CA) certificates are installed into applications that authenticate certificates. For example, Web browsers are usually distributed with several trusted (root) CA certificates pre-installed. If the server certificate is not signed by a well-known certificate authority and you want to ensure that the server's certificate will be authenticated by the client, it is good practice for the server to issue a certificate chain that terminates with a certificate that is signed by a well-known certificate authority. See also certificate chain, private key, public key.
Authentication that requires both the client and server to present a certificate before the connection thread is enabled between the two. With two-way SSL authentication, WebLogic Server not only authenticates itself to the client (which is the minimum requirement for certificate authentication), it also requires authentication from the requesting client. Clients are required to submit digital certificates issued by a trusted certificate authority. This type of authentication is useful when you must restrict access to trusted clients only. Two-way SSL authentication is a form of mutual authentication. See also authentication, digital certificate, mutual authentication, Secure Sockets Layer (SSL), trusted (root) certificate authority.
A WebLogic Server 6.x security realm. The UNIX security realm executes a small native program,
wlauth, to look up Users and Groups and to authenticate users on the basis of their UNIX login names and passwords. The
wlauth program uses PAM (Pluggable Authentication Modules), which allows you to configure authentication services in the operating system without altering applications that use the service. In WebLogic Server 7.0 and later, you can only use the UNIX security realm when using Compatibility security. See also authentication, authorization, Compatibility security, group, security realm.
An entity that can be authenticated. A user can be a person or a software entity, such as a Java client. Each user is given a unique identity within a security realm. For more efficient security management, BEA recommends adding users to groups. A group is a collection of users who usually have something in common, such as working in the same department in a company. Users can be placed into groups that are associated with security roles, or be directly associated with security roles. See also entity, group, security role, WebLogic resource.
WebLogic Server implements J2EE component technologies, which include servlets, JSP Pages, and Enterprise JavaBeans. To build a WebLogic Server application, you must create and assemble components, using the service APIs when necessary. Components are executed in the WebLogic Server Web container or EJB container. Web components provide the presentation logic for browser-based J2EE applications. EJB components encapsulate business objects and processes. See also WebLogic container, Windows NT security realm.
To promote fast development and portability, J2EE identifies common services needed by components and implements them in the container that hosts the component. Containers provide the life cycle support and services defined by the J2EE specifications so that the components you build do not have to handle underlying details. A component has only the code necessary to describe the object or process that it models. It has no code to access its execution environment or services such as transaction management, access control, network communications, or persistence mechanisms. These services are provided by the container, which is implemented in WebLogic Server. Additionally, WebLogic containers give applications access to the J2EE application programming interfaces (APIs). WebLogic containers are available for use once the server is started. This component/container abstraction allows developers to work within their fields of expertise. WebLogic Server provides two types of containers: the Web container and the EJB container. See also WebLogic component, Windows NT security realm.
WebLogic Server implements J2EE services, which include access to standard network protocols, database systems, and messaging systems. To build a WebLogic Server application, you must create and assemble components, using the service APIs when necessary. Web applications and EJBs are built on J2EE application services, such as JDBC, Java Messaging Service (JMS), and Java Transaction API (JTA). See also WebLogic component.
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. See also entity.
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. See also security provider.
Any of the security providers that are supplied by BEA as part of the WebLogic Server product. These providers were developed using the Security Service Provider Interfaces (SSPIs) for WebLogic Server. See also custom security provider, security provider, Security Service Provider Interfaces (SSPIs).
The WebLogic Server subsystem that implements the security architecture. This subsystem comprises there major components: the WebLogic Security Framework, the Security Service Provider Interfaces (SSPIs), and the WebLogic security providers.
A collection of servers, services, interfaces, machines, and associated WebLogic resource managers defined by a single configuration file. See also WebLogic resource.
A WebLogic Server 6.x security realm. The Windows NT Security realm uses account information defined for a Windows NT domain to authenticate Users and Groups. In WebLogic Server 7.0 and later, you can only use the Windows NT security realm when using Compatibility security. See also authentication, authorization, Compatibility security, group, security realm, user.