|
|
The following sections describe the fundamentals of the ALES services:
Authentication answers the question, Who are you? using credentials such as username and password combinations. An Authentication provider is used to prove the identity of users or system processes. The Authentication provider also stores, transports, and makes identity information available to various components of a system when needed.
Authentication is the process of verifying an identity claimed by or for a user or system process. An authentication process consists of two steps:
The Authentication providers support numerous methods of authentication services, including user username/password and identity assertion. In addition, a set of Authentication providers is supplied that access various types of user directories and identity tokens.
Figure 4-1 shows how the authentication process works for a web application that requires a username and password to perform the login. When a user attempts to log into a system using a username and password combination, the Authentication provider establishes trust by validating that username and password. This process also requires the use of a Login Module as described in Identity Assertion.
| Note: | Because the authentication service is implemented using the JAAS standard, developers of custom Authentication providers are involved with the JAAS process directly. |
The authentication process requires a valid list of users and groups, through which their identity can be verified. ALES supports any number of LDAP servers or a database.
Users must be authenticated whenever a request is made to access a protected resource. For this reason, each user is required to provide a credential (for example, a password). The following types of authentication are supported by the Authentication providers:
You can use one of the Authentication providers provided as part of ALES or you can create a custom authentication provider to perform a different type of authentication. Support for the following methods of user and password authentication include:
In username and password authentication, a user ID and password are requested from the user and sent to the Security Framework. The Security Framework authenticates the user.
You can use Secure Sockets Layer (SSL) or Hyper-Text Transfer Protocol (HTTPS) to provide an additional level of security to username and password authentication. Because SSL encrypts the data transferred between the client and the Security Framework, the username and password are encrypted and not transferred in clear text. Therefore, ALES services can authenticate the user without compromising the confidentiality of the username and password.
Perimeter authentication is the process of authenticating the identity of a remote user outside of the application server domain. You can use an Identity Assertion provider to establish perimeter authentication—a special type of authentication that uses tokens. The Security Framework supports identity assertion providers that perform perimeter-based authentication and handle multiple security token types and protocols.
ALES services are designed to extend the single sign-on concept all the way to the perimeter by using identity assertion (see Figure 4-2). Provided as a critical piece of the Security Framework, the concept of identity assertion allows you to use the authentication mechanism provided by perimeter authentication schemes such as the Checkpoint OPSEC, the emerging Security Assertion Markup Language (SAML), Simple and Protected Negotiation Mechanism (SPNEGO), or enhancements to protocols such as Common Secure Interoperability (IIOP-CSIv2) to achieve this functionality.
Perimeter authentication is typically accomplished by the remote user specifying an asserted identity and some form of corresponding proof material, normally in the form of a passphrase, which is used to perform the verification. The authentication agent, the entity that actually vouches for the identity, can take many forms, including: Web Server, VPN, firewall, enterprise authentication service, or some other form of global identity service. Each of these forms of authentication has one common characteristic– they all perform an authentication process that results in an artifact or token presented to vouch for the authenticated user at a later time.
Currently, the format of the token varies from vendor to vendor, but there are efforts underway to define a standard token format. SAML is an emerging XML-based protocol for exchanging information securely. In addition, there is a current standard for identity attribute certificates that is based on the X.509 standard for digital certificates. But, if the applications and the infrastructure on which they are built are not designed to support this concept, enterprises are still forced to require remote users re-authenticate to the applications within the network. You can develop custom authentication providers that support different token types, including SAML.
Support for perimeter authentication requires the use of one or more identity assertion providers designed to support one or more token formats. You can implement multiple and different identity assertion providers. The tokens are transmitted as part of any normal business request, using the mechanism provided by each protocol supported. Once a request is received, the entity that handles the processing of the protocol message recognizes the existence of the token in the message. This information is used in a call to the Security Framework, which then calls the appropriate identity assertion provider to handle the verification of the token. It is the responsibility of the identity assertion provider implementation to perform whatever actions are necessary to establish validity and trust in the token and to provide the identity of the user with a reasonable degree of assurance, without the need for the user to re-authenticate to the application.
The passphrase entered by the user is a string of characters (typically, much longer than a password) used to create a digitally-encrypted signature (or private or secret key). The passphrase adds an extra level of authentication security to ensure that you are who you say you are.
Identity Assertion providers support the mapping of a valid token to a user. You use an Identity Assertion provider to support the specific types of tokens that you use to assert the identities of users or system processes. You can develop an Identity Assertion provider to support multiple token types, but the administrator must configure the Identity Assertion provider so that it validates only one active token type. While you can have multiple Identity Assertion providers in a application domain with the ability to validate the same token type, only one Identity Assertion provider can actually perform this validation.
The security architecture supports Identity Assertion providers that perform perimeter-based authentication to Web Servers, firewalls, and VPNs. Identity Assertion providers support different token types, such as X.509 certificates (Kerberos), SAML and handles multiple security protocols (such as SOAP and IIOP-CSIv2). When used with an Authentication provider Login Module, 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. The Identity Assertion providers in ALES support the following token types:
When perimeter authentication is used (see Figure 4-3), a token from outside of the application domain is passed to an Identity Assertion provider responsible for validating the type of token configured as active. If the token is successfully validated, the Identity Assertion provider maps the token to a username, sends that username back, and the authentication process continues. Specifically, the username is sent through a JAAS Callback Handler and is passed to each configured Authentication provider Login Module, so that the Login Module can populate the subject with the appropriate principals. Perimeter-based authentication requires the same components as the authentication process, but includes an Identity Assertion provider.
Identity Assertion providers are used as part of perimeter-based authentication process to validate the token type, and then map it to a username. It also specifies a list of trusted client principals to use for identity assertion. The wildcard character (*) can be used to verify that all principals are trusted. If a client is not listed as a trusted client principal, the identity assertion fails and the login is rejected. You can use an Identity Assertion provider in place of an Authentication provider if you create a Login Module for the Identity Assertion provider, or you can use an Identity Assertion provider in addition to an Authentication provider if you want to use the Authentication provider Login Module.
You can configure multiple Identity Assertion providers to support different types of tokens within the same application domain, but you do not need Identity Assertion provider unless you are supporting perimeter authentication. Two Identity Assertion providers are supplied: one supports X.509 and IIOP- CSIv2 and one supports SAML. A third Identity Assertion provider supports identity assertion using HTTP authentication tokens from the SPNEGO protocol, to enable single sign-on Cross-Platform authentication capabilities.
When used with a Login Module, Identity Assertion providers support external authentication of a user based on industry standard methods, for example, perimeter authentication or single sign-on. An Identity Assertion provider can generate a local subject. The Login Module that an Identity Assertion provider uses can be part of BEA’s authentication provider or one developed by a third party.
Unlike simple authentication, the Login Modules that Identity Assertion providers use do not verify proof material such as usernames and passwords; they simply verify that the user exists. The token provides the proof that the user is trusted.
Role mapping is the process by which the security service compares users or groups against a security role condition to determine whether a security role is granted. Role mapping occurs dynamically at runtime, just before an access decision is rendered for a protected resource.
The Role Mapping provider determines dynamic roles for a specific user with respect to a specific protected resource. The Security Framework calls each Role Mapping provider that is configured as part of an authorization decision. It can also be used to determine the dynamic roles for the specific user to support personalization (for example, with BEA WebLogic Portal 8.1). Figure 4-4 shows how the Role Mapping provider interacts with the Security Framework to create dynamic role associations.
The role mapping process is initiated when a user or system process requests a resource on which it attempts to perform an operation. The resource container that handles the type of resource requested receives the request (for example, the EJB container receives the request for an EJB resource). The resource container calls the Security Framework, and then passes in the request parameters, including information such as the subject (users and groups) of the request, the resource, and the action. The Security Framework calls each configured Role Mapping provider to obtain a list of the roles that apply. If an access control policy specifies that the requestor is entitled to a particular role, then 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 resource or the resource container are evaluated. The list of roles is returned to the 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 provider is a set of roles that apply to the principals stored in a subject at the time of the request. These roles can then be used to make authorization decisions for protected resources, as well as a resource container and application code. For example, an EJB could use the Java 2 Enterprise Edition (J2EE) method to retrieve fields from a record in a database, without having knowledge of the business policies that determine whether access is allowed.
Authorization is the process whereby the interactions between users and resources are controlled, based on user identity or other information. In other words, authorization answers the question, Can this user access this resource under these conditions? An Authorization provider is used to limit the interactions between users and resources to ensure integrity, confidentiality, and availability. You can optionally define a time constraint for an authorization policy to answer the question, When can the user access the resource?
The Authorization service determines whether or not a user can access a resource based on the user’s name, group, or role and the authorization policy assigned to the requested resource. Figure 4-5 illustrates how an Authorization provider, and the associated Adjudication and Role Mapping providers, interact with the Security Framework during the authorization process.
The authorization process is initiated when a user request is made to perform an operation on a resource. The resource receives the request, calls the Security Framework, and then passes the request parameters to the security providers, including information such as the subject (users and/or groups) of the request, the resource requested, and the action. The Security Framework calls the configured Role Mapping provider using the request parameters to dynamically compute a list of roles to which the user making the request is entitled, and then passes the list of applicable roles back to the Security Framework.
The Authorization provider determines whether the user is entitled to perform the requested action on the resource, based on the user's profile and the supplied resource and the user’s role, and makes an access control decision.
The following sections describe authorization concepts and functionality:
ALES products can access user directories from a variety of sources, including: application databases, Lightweight Directory Access Protocol (LDAP) directory servers, network databases, and others. The type of information or attributes collected—a method typically referred to as profiling—also varies and typically includes: name and address, phone, e-mail address, personal preferences, and more. The information contained in these directories is the core of any authentication service and is key to providing an effective identity management solution.
Users and group information, along with their attributes, are cached in a database table. User data is then available for access to create or enforce authorization policies.
ALES has no control over your user community; your method of storage is completely under your control. For administrative purposes, however, all users must be a member of at least one group.
A resource is a structured object used to represent an underlying entity that can be protected from unauthorized access using security roles and policies. Resources are hierarchical by nature. Therefore, the level at which you define these roles and policies is up to you. For example, you can define roles and policies on entire EAR, an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB. Some typical resources you might want to protect include.
| Note: | This ALES release includes an example that demonstrates the principles of an EJB application functioning under the ALES framework. The example shows how the additional layer provided by ALES can make an EJB application more secure by defining custom dynamic authorization policies without any changes in the application or the deployment descriptors. The example consists of an EJB application that runs on the server side, an EJB client, and the sets of resources, policies, and users that determine the access rights. |
| Note: | The example is installed in BEA_HOME\ales30-ssm\wls-ssm\examples\EJBAppExample. |
A resource has no protection until it is protected by a policy. In early security systems, an access control list (ACL) was used to protect resources. ALES authorization policies replace ACLs through the use of role-based access control (RBAC). Like Login Modules for Authentication providers, an access decision is the component of an Authorization provider that actually answers the question, Is access allowed? Specifically, an access decision is asked whether a subject has permission to perform a given operation on a resource, with specific parameters in an application. Given this information, the access decision responds with a result of PERMIT, DENY, or ABSTAIN.
You create an authorization policy by establishing the permissions, or privileges, for access, based on the resource you want to protect and the role of the requestor; authorization policy focuses on the business process or role, rather than on a user or group. Using RBAC you separate the process of identifying the requestor (defined through a separate authentication process), from the process of authorization (defined by an access decision). The performance improvement gained by this separation is really quite significant. Once the user is authenticated, the access decision can be made more quickly because there is no need to re-authenticate. The importance and benefit of basing access decisions on roles becomes quite apparent as you can assign large groups of users, who’s business functions are the same, to the same role. Because role changes less frequently than user or group status, this mechanism is easily scalable.
You assign authorization policies to any of your resources (for example, a URL, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a resource (for example, an EJB method or a servlet within a web application). If you assign a authorization policy to a type of resource, all new instances of that resource inherit that policy.
To use a user or group to create an authorization policy, the user or group must be defined for the authorization provider that is configured for the service module to which the provider is associated. For efficiency, this is typically done through the use of roles rather than user or groups. To use a role to create a role mapping policy, the role must be defined for the Role Mapping provider that is configured for that service module. All authorization and role mapping policy data is stored in the policy database. When the Authorization provider and Role Mapping provider are configured, their configurations are also stored in the policy database.
| Note: | Although you have the option of basing an authorization policy on a user or group, BEA recommends basing authorization policies on roles. Basing authorization policies on roles is a more efficient method of management. |
This release of ALES provides built-in attribute retrievers that you can configure directly in the console. Attribute retrievers are used by ASI Authorization and ASI Role Mapping providers to retrieve attributes for use in policies. In prior releases of ALES, you needed to write code to create an attribute retriever, as described in Attribute Retriever.
Built-in attribute retrievers are typically configured with a set of connection properties and credentials to connect to the data source. The configured attribute retriever can have a set of attributes with queries defined to retrieve the attribute value during policy evaluation. The attribute retrievers take care of executing the query against the configured data source during policy evaluation, and return the result to ALES to make a decision.
Any changes to the configured attribute retrievers would need to be distributed to the SCMs, and the SSMs restarted for the new configuration to take effect.
If one of the preconfigured attribute retriever types does not meet your needs, you can still create a custom attribute retriever from code and then manage it from the console.
The following attribute retrievers types are provided. See the online help for information on configuring each specific attribute retriever type.
RDBMS Attribute Retrievers retrieve attribute values from an RDBMS database. You configure the retriever with a database URL, driver, and credentials to access the database. The driver URL can have a comma separated list of server URLs for failover. You then create attributes for these retrievers, with a query to retrieve attribute values. For example, to retriever the “user_type” from a database for a given user, you could use a query similar to SELECT user_type FROM customer WHERE user_id=%sys_user%. Queries can optionally contain ALES-defined system attributes, as in the example. Multiple attributes can be defined with comma-separated list of names for the attribute name field. If so defined, the query would have to contain multiple attributes in the same order as defined in the attribute name. For example, if the attribute name is defined as id,postalcode, the query could be similar to SELECT id, postalcode FROM customer. Optionally, attribute values can be cached based on the business requirement using the use cache and the TTL configuration parameters.
The created built-in attributes require an equivalent ALES dynamic attribute with the same name to be used as part of constraints for policy evaluation.
LDAP Attribute Retrievers retrieve attribute values from an LDAP database. You configure the connection properties, such as host name, port and credentials. Host name can be a comma-separated list of servers if failover is desired. You then create built-in attributes for the configured retriever with a query to locate the attribute. The query can be an entry of the form uid=%sys_user%,cn=employees,ou=enterprisesecurity,ou=security,dc=amer,dc=bea,dc=com. Optionally, configure the filter attribute if the search needs to be further narrowed down. For example &(objectclass=*)(transactioncode= %sys_rule_obj_q%. Note that the query and filters attributes can have optional ALES system attributes that are substituted with values before the query is run.
Make sure to create ALES dynamic attributes with the same name as that of the built-in attributes to be used as part of constraints.
Service Data Objects (SDO) is a joint BEA/IBM specification that identifies a unified framework for data application development. It works with data from multiple data sources in the form of physical or Logical data services from ALDSP. The ALDSP services can in turn depend on multiple data services to retrieve data.
To retriever attribute values from an ALDSP server, configure an SDO Attribute retriever. Configuration of the SDO retriever requires the ALDSP server lookup information and credentials. The service lookup entry would be of the form ld:DataServices/CustomerManagement/CustomerProfile. The servers can be a comma-separated list of servers for failover. You also configure the initial context factory implementation to use, and make sure the jars are available in the classpath at runtime. For example, if the WebLogic initial context factory is used (weblogic.jndi.WLInitialContextFactory), make sure the WebLogic client jar is available in the CLASSPATH at runtime. Otherwise, you generate a ClassNotFoundException exception.
The application name entry is the name of the application to connect to on the hosted ALDSP server. Configure the login credentials to connect to the server.
| Note: | In this release SDO attribute retrievers are supported only when running on WLS SSMs. Also, there is no caching support for SDO Attributes with this release. |
ALES Identity Attribute Retrievers are used to retrieve the value of an identity attribute from the ALES database. In releases of ALES prior to 3.0, metadirectory configuration was used to access identity attributes from ALES. This was done by configuring the "Use Metadirectory" option on the ASI Authorizers page. This functionality is now available via the ALES Identity Attribute Retriever.
Create the retriever with the driver URL, connection properties, and credentials to connect to the ALES database. There is no need to create attributes for the ALES Identity Retriever. You create ALES identity attributes using the ALES Administration Console and then use the attributes in the policy constraints as needed.
Make sure to associate and initialize the newly-created identity attributes to the respective identity directories.
Custom Attribute Retrievers are used if the built-in attribute retrievers are not suitable for your needs. You could create a custom attribute retriever plug-in and configure a custom retriever using the console. I
In the prior release, custom retrievers were configured on the advanced settings of the ASI Authorization and Role Mapping provider. In the current release, this configuration is done by creating a new custom retriever for the ASI Authorization provider and then specifying the fully-qualified package (with classname) for the plug-in to be loaded at runtime.
Creating attributes for the custom retrievers is optional and should be done only when attribute-specific caching is required. To do this, create one or more dynamic attributes and use them with constraints for policy evaluation.
When upgrading from a prior version of ALES, the configuration related to Metadirectory and custom attribute retrievers is preserved:
The WebLogic Server 9.x/10.0 SSM uses a different security framework from the one used in the WLS 8.1 SSM and the other ALES SSMs.
As a consequence, when you use the WLS 9.x/10.0 SSM you must use the WebLogic Administration Console to configure attribute retrievers and their related attributes. The configuration process is similar to that of the other SSMs types on the ALES Administration Console.
A ContextHandler is a high-performing 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 resource container to pass additional information to a 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 resource and the security provider. Each name/value pair in a ContextHandler is known as a context element and is represented by a Context Element object.
For example, with WebLogic Server 8.1, three types of resource containers pass Context Handlers to the Security Framework: the Servlet, EJB, and Web Service containers. Thus, URL (web), EJB, and Web Service resource types have different context elements whose values Authorization and Role Mapping providers can inspect. An implementation of the Audit Context interface (used when a security provider is implemented to post audit events) may also examine the values of context elements.
Adjudication involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured in a application domain, by weighing the result of each Authorization provider’s access decision. An Adjudication provider tallies the results that multiple access decisions return, and determines the final PERMIT or DENY decision. An Adjudication provider may also specify what to do when an answer of ABSTAIN is returned from an access decision from a single Authorization provider.
If there are multiple Authorization providers configured, the Security Framework delegates the job of reconciling any conflicts in the access decisions rendered by the Authorization providers to the Adjudication provider, which determines the ultimate outcome of the access decision. The Adjudication provider returns either a TRUE or FALSE verdict to the Authorization providers, and then forwards it to the resource through the Security Framework.
In the ALES architecture, an Auditing provider is used to support auditing services, for example, using the Log4j Auditing Channel provider. An auditing service is used to collect all security event information and distribute that information as configured.
If configured, the Security Framework calls the Auditing provider before and after security operations are performed (such as authentication or authorization), enabling audit event recording. The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and severity levels. The records that contain the audit information may be written to output repositories such as an LDAP server, a database, or a file.
An auditing service is a process whereby information about service requests and the outcome of those requests are made available to configured auditing providers. Auditing provides an electronic trail of transaction activity, and can include changes to system configuration parameters, policy changes, transactions, and security breach attempts of any type. For each audit item, the information may include who, what, when, where, and sometimes why.
Records can be directed to a file, a database or other persistent storage medium, and then used to generate reports from any reporting generating software you choose. Figure 4-6 shows how the Auditing provider interacts with the Security Framework and other types of security providers using a Authentication provider as an example.
The auditing process is initiated when a resource container passes authentication information for a user (for example, a username and password combination) to the Security Framework as part of a login request. The Security Framework passes the information associated with the login request to the configured Authentication provider. The Authentication provider passes the audit event back through the Security Framework, which then makes that audit event available to the configured Auditing provider.
The performance statistics feature enables the collection of data about authentication and authorization for purposes of troubleshooting and performance analysis. The performance statistic feature is controlled by an Auditing security provider, the PerfDBAuditor provider. Performance statistics are gathered for each Security Service Module in your AquaLogic Enterprise Security installation. In order to collect performance statistics for an SSM, you must enable and configure a PerfDBAuditor provider for that SSM.
See the Performance Statistics “how to” document for additional information.
Credential mapping is the process of looking up the authentication credentials associated with a user for a given resource.
The Credential Mapping service provides authentication credentials for a user of another application, for example, some type of mainframe transaction processing, a database system, or a legacy application. Three Credential Mapping providers are supplied: one supports usernames and passwords stored in a relational database; one supports usernames and passwords stored in a WebLogic Server 8.1 embedded LDAP directory (this provides support for WebLogic Portal 8.1); and one produces SAML credentials.
Figure 4-7 illustrates how the Credential Mapping provider interacts with the Security Framework to support the credential mapping service.
Security services are based on a set of Security Service Provider Interfaces (SSPIs). Developers and third-party vendors can use the SSPIs to develop custom security providers for ALES. SSPIs are available for Authorization, Role Mapping and Adjudication; Auditing; Authentication, and Identity Assertion; and Credential Mapping (for a description of providers, see Table 4-1). The SSPIs allow customers to use their security providers to secure resources. Customers can use the SSPIs to develop custom security providers or they can purchase customer security providers from third-party vendors.
| Note: | In addition, you can use the following AquaLogic Enterprise Security security providers by adding them to your WebLogic Server security realm: |
| Note: | To assist customers in developing custom security providers, sample custom security providers are also available from the BEA dev2dev web site at http://dev2dev.bea.com. For more information on developing custom security providers, see Developing Security Providers for BEA AquaLogic Enterprise Security. |
|