Access Manager uses a Java technology-based architecture for scalability, performance, and ease of development.
Access Manager leverages industry standards including HyperText Transfer Protocol (HTTP), eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Security Assertions markup Language (SAML) specification. The Access Manager internal architecture is multi-layered and includes a presentation layer, web services, core components, an integrated framework, and a plug-ins layer.
Custom applications access the Access Manager web services through the Access Manager client application programming interfaces (APIs) installed on each protected resource. Custom plug-in modules interact with the Access Manager service provider interfaces (SPIs) and plug-ins framework. The plug-in modules retrieve information from the Access Manager information tree and deliver required information to other plug-ins when necessary, and to the Access Manager framework for data processing.
Web services follow a standardized way of integrating Web-based applications using XML, SOAP, and other open standards over an Internet protocol backbone. Web services enable applications from various sources to communicate with each other because web services are not tied to any one operating system or programming language. Businesses use web services to communicate with each other and with clients without having to know detailed aspects of each other's IT systems.
Access Manager provides web services that use XML and SOAP over HTTP. Access Manager web services are designed to be centrally provided in your network for convenient access by your client applications. The following table summarizes the web services provided in Access Manager.
Table 1–1 Access Manager Web Services
Web Service Name |
Description |
---|---|
Verifies that a user really is the person he claims to be. |
|
Evaluates policies associated with a user’s identity, and determines whether an authenticated user has permission to access a protected resource. |
|
Enables single sign-on sessions among different business domains. Allows business partners to securely exchange authentication and authorization information over the Internet. |
|
Enables a user to log in at one service provider’s site and move to an affiliated service provider site without having to re-authenticate or re-establish his identity. |
|
Maintains information about the user’s interaction with various applications the user accesses. |
Access Manager uses both eXtensible Markup Language (XML) files and Java interfaces to and manage web services and web service configuration data. An Access Manager XML file is based on a structure defined in a corresponding DTD file. The DTD file defines the elements and qualifying attributes needed to form a valid XML document. Access Manager includes DTD files that define the structure for the different types of XML files it uses. The DTDs are located in AccessManager-base/SUNWam/dtd. The file sms.dtd defines the structure for all XML service files. All XML service files are located in /etc/opt/SUNWam/config/xml.
Do not modify any of the Access Manager DTD files. The Access Manager APIs and their internal parsing functions are based on the default definitions. Alterations to the DTD files may hinder the operation of Access Manager.
The core components provide the logic that performs the main Access Manager functions. The core components work with services that run within Access Manager. These internal services process data solely for use by Access Manager. The following table lists the core Access Manager components and internal services along with brief descriptions of what they do.
Table 1–2 Access Manager Core Components and Internal Services
Core Component or Service |
What it Does |
---|---|
Authentication component |
Validates user’s credentials and verifies that the user is who he claims to be. |
Authorization (Policy) component |
Evaluates policies to determine whether the user has permission to access the requested resource. |
Security Assertion Markup Language (SAML) component |
Provides a protocol-based alternative to using cookies for performing a single sign-on session. |
Identity Federation component |
Enables user to access resources provided by multiple business partners in a single sign-on session. |
User Session Management component |
Maintains information about user session, and enforces timeout limits. Provides continued proof of identity to enable single sign-on sessions. |
Logging service |
Tracks a user’s interactions with web applications. Creates log messages to form an audit trail of important events within the system. |
Naming service |
Enables a client to locate other Access Manager services such as User Session Management Service, Logging Service, Policy Service, and so forth. Defines URLs used to access these internal services. |
Platform service |
Manages configurable attributes used in an Access Manager deployment. |
Client Detection service |
Detects the client type of the browser being used to access the Access Manager application. Client types include HTML, WML, and other protocols. |
Enterprise resources cannot be protected by Access Manager until you install Access Manager client APIs on the Web Server or Application Server that you want to protect. The client APIs mirror the APIs and functionality contained in the Access Manager core components: Authentication, Authorization (Policy), SAML, Identity Federation, and User Session.
The framework layer is where the Access Manager business logic is implemented. Each core component uses its own framework to retrieve customer data from the plug-in layer and to provide data to the core components. The Access Manager framework integrates all of these frameworks to form one layer in the architecture that is accessible to all core components and all Access Manager plug-ins.
The Access Manager SPIs work with plug-ins to provide customer data to the framework for back-end processing. Some customer data comes from external data base applications such as identity repositories. Some customer data come from Access Manager plug-ins. You can develop custom plug-ins to work with Access Manager SPIs.
For a complete listing of Access Manager SPIs, see the Javadoc. The following table lists the plug-ins that are installed with Access Manager and a brief description what each plug-in does.
Table 1–3 Access Manager Plug-ins
Plug-in |
Description |
---|---|
Accesses user data in a specified identity repository to determine if user’s credentials are valid. |
|
Aggregates policies and rules to determine whether a user is authorized to access a protected resource. |
|
Manages configuration data used in each core component framework: authentication, authorization, SAML, session, logging, and identity federation. Provides configuration data to any Access Manager plug-in or component that needs the data. |
|
Aggregates policies and rules to determine the scope of a network administrator’s authority. |
|
Authenticates identities and returns identity information such as user attributes and membership status. |
|
Creates and modifies users and stores information in the user branch of the identity repository. Implements user management APIs used in previous Access Manager releases. |
You install an Access Manager Policy Agent on a protected resource to enforce the policy decisions determined by the Policy Service. The policy agent intercepts requests from applications, and redirects the requests to Access Manager for authentication. Once the user is authenticated, the policy agent communicates with the Policy Service. The policy agent allows the user access or denies the user access depending upon the result of policy evaluation.
Access Manager includes new components that enable you to implement authentication and authorization solutions without having to make changes in your existing user directory information tree.
In Access Manager an access control realm is a group of authentication properties and authorization policies you can associate with a user or group of users. Realm data is stored in a proprietary information tree that Access Manager creates within a data store you specify. The Access Manager framework aggregates policies and properties contained in each realm within the Access Manager information tree.
By default, Access Manager automatically inserts the Access Manager information tree as a special branch in Sun Java Enterprise System Directory Server, apart from the user data.
You can use access control realms while using any user database. The following figure illustrates the Access Manager information tree configured in a separate data store from the identity repository.
When a user logs into an application, Access Manager plug-ins retrieve all user information and access information that Access Manager needs to form a temporary, virtual user identity. Authentication service and Policy service use the virtual user identity to authenticate the user and to enforce authorization policies. The virtual user identity is destroyed when the user’s session ends.
An identity repository is a database where you can store user attributes and user configuration data. Previous versions of Access Manager relied on Sun Java System Directory Server as the only supported identity repository and the only supported software for creating, managing, and storing user data.
Access Manager provides an identity repository plug-in that connects to an identity repository framework. This new model enables you to view and retrieve Access Manager user information without having to make changes in your existing user database. The Access Manager framework integrates data from the identity repository plug-in with data from other Access Manager plug-ins to form a virtual identity for each user. Access Manager can then use the universal identity in authentication and authorization processes among more than one identity repository. The virtual user identity is destroyed when the user’s session ends.
You can configure the Identity Repository Management Service per realm to use its own list of Identity Repositories.
Using realm-based configuration, you can specify a single Identity Repository that will store service configurations for both users and roles. The Identity Repository Service provides a list of Identity Repositories that can provide user attributes to Policy, SAML , and Liberty services. The Identity Repository Services pluggable interface combines attributes obtained from different repositories. Identity Repository plug-ins provide interfaces to create, read , edit, and delete objects such as Realm, Role, Group, User, and Agent.
The default identity repository plug-in is designed to work with Sun Java Directory Server which is based on LDAP. In previous Access Manager versions, the functionality of this default plug-in was provided by the AM SDK component. In Access Manager 7.0, the AM SDK functionality still exists, but now in plug-in form.
When you install Access Manager, you are asked to choose either Realm Mode or Legacy Mode.
Realm mode is new in Access Manager 7.0, and is based on the Access Manager information tree and Identity Repository Management Service described in the previous sections. Realm mode is appropriate in most new Access Manager deployments where you want to keep identity repositories independent of access management, or where you cannot maintain user data within the required object classes of Sun Java System Directory Server.
If you choose Realm Mode at installation, then after installation your identity repositories can exist in any of the following configurations:
In the same Directory Server instance and the same suffix as the Access Manager information tree.
In the same Directory Server instance but in a different suffix as the Access Manager information tree.
In a different directory server instance from the Access Manager information tree.
Legacy Mode is based on the Access Manager 6.3 architecture. This legacy Access Manager architecture uses the LDAP directory information tree (DIT) that comes with Sun Java System Directory Server. In Legacy Mode, both user information and access control information are stored in LDAP organizations. When you choose Legacy Mode, an LDAP organization is the equivalent of an access control realm. Realm information is integrated within LDAP organizations.
Legacy Mode is appropriate in deployments where you want to use Access Manager user management. Legacy Mode is typically used in deployments where Access Manager is built upon Sun Java System Portal Server or other Sun Java System communication products that require the use of Sun Java System Directory Server as the central identity repository.
If you choose Legacy Mode during installation, then after installation the top-level ream resides in the same Directory Server branch as the Access Manager information tree, and user information is intermingled with access information.
The following table compares realm mode and legacy mode.
Table 1–4 Comparison of Realm and Legacy Modes
Realm Mode |
Legacy Mode |
|
---|---|---|
Supports all new Access Manager 7 2005Q4 features. |
Yes |
Yes |
Supports identity repositories in Sun Java System Directory Server and in other data stores. |
Yes |
Yes |
Supports Access Manager 6 user management features. |
No |
Yes |
Can coexist with Access Manager 6 2005Q1 in multiple-server installations. |
No |
Yes |
Before installation, identity repository can exist in Sun Java Directory Server . |
Yes |
Yes |
Before installation, identity repository can exist in an LDAP version 3 compliant directory server. |
Yes |
No |
For more information about realm and legacy modes, see the Sun Java System Access Manager 7 2005Q4 Release Notes.
The Distributed Authentication user interface enables a policy agent or an application that is deployed in a non-secured area to communicate with the Access Manager Authentication Service that is installed in a secured area of the deployment. Typically, the non-secured policy agent or application is separated from Access Manager by two firewalls. In such deployments, policy agents and applications are not usually allowed to communicate across two firewalls.
You can install the distributed authentication user interface on a J2EE web container within the non—secure layer of an Access Manager deployment. The web browser communicates an HTTP request to the remote authentication user interface, which in turn presents a login page to the user. The web browser sends user login information through a firewall to the remote authentication user interface. The remote authentication user interface communicates through the second firewall to the Access Manager Server. For detailed illustration and process flow, see User Authentication. For detailed installation and configuration instructions, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.
The Delegation plug-in works together with the Identity Repository plug-in to determine a network administrator’s scope of privileges. Default administrator roles are defined in the Identity Repository plug-in. The Delegation plug-in forms rules that describe the scope of privileges for each network administrator, and also specifies the roles to which the rules apply. The following is a list of roles defined in the Identity Repository, and the default rule the Delegation plug-in applies to each role.
Table 1–5 Access Manager Roles and Scope of Privileges
Identity Repository Role |
Delegation Rule |
---|---|
Can access all data in all realms of the Access Control information tree. |
|
Can access all data within a specific realm of the Access Control information tree. |
|
Can access all policies in all realms of the Access Control information tree. |
|
Can access policies only within the specific realm of the Access Control information tree. |
Authentication service and Policy service use the aggregated data to perform authentication and authorization processes. The Delegation plug-in code is not public in Access Manager.
The Service Configuration plug-in stores and manages data required by other Access Manager plug-ins. In previous versions of Access Manager, the functionality provided by the Service Configuration plug-in was known as the Service Management Service (SMS).