|
| |
| Sun Java System Identity Server 2004Q2 Technical Overview | |
Chapter 4
Services ManagementSun Java™ System Identity Server comes with its own set of core services which make user access and policy management possible. Identity Server also provides the necessary tools for administrators to define, integrate and manage groups of attributes which form service plug-ins. Both eXtensible Markup Language (XML) files and Java™ interfaces are used for this purpose.
This chapter describes how Identity Server core services and service plug-ins work together. Topics included in this chapter are:
How Services Work in Identity ServerIn Identity Server, a service is a group of attributes that are managed together by the Identity Server console. The attributes can be just bits of related information such as an employee’s name, job title, and email address. But attributes are typically used as configuration parameters for a software module such as a mail application or payroll service.
A company’s mail service provides a good example of how a service plug-in can extend the Identity Server core services. In this example, a company stores in its Directory Server one user profile for each of its employees. Now the company wants to leverage those user profiles to work with its mail application. First, the developer creates a service definition in the form of an XML file. The XML file describes the object classes and attributes that will be used by the mail application. Mail-related attributes might include the employee’s email address and password, the name of the mail server he uses, his email storage limit, time-out limit, and so forth.
Core Services
Identity Server comes with a number of services that work together to perform its basic functions. See Identity Server Core Services for a complete services listing. The following example illustrates how Authorization, Session, Policy, Naming and Logging Services work together.
When the employee logs in to a mail application, the application first communicates with Identity Server to authenticate, or verify, the employee’s user ID and password. The Authentication Service verifies that the login credentials the user has provides matches the user profile stored in Directory Server.
Identity Server also issues a request to the Naming Service which defines the URLs used to access other Identity Server services. The Naming Service returns locators for the Policy Service which is used to examine all policies assigned to the user.
Once the user is authenticated and granted access to a resource, Identity Server issues a session token or marker that helps to keep track of things such as when the user logged in and how long it’s been since the user stopped actively using the application. The Logging Service records information such as user activity, traffic patterns, and authorization violations. These records are useful when troubleshooting.
Service Plug-Ins
In the same example, the mail application works with the APIs in the Identity Server Software Development Kit (SDK) layer. Identity Server validates the attribute values associated with the user’s profile against the mail service definition. This helps the mail application to determine which mail server the employee is authorized to use, whether the employee is within his email storage limit, whether he’s exceeded his time-out limit, and so forth. Based on each of these determinations, the mail application either grants or denies the employee access to his email. If the employee is granted access, the Identity Server session management service comes into play. When the employee’s mail session sits idle for too long, for example, Identity Server communicates with the mail application which causes the mail session to time-out or expire.
The Identity Server SDK gives application developers the interfaces necessary to register and un-register services with Identity Server, as well as to manage service attributes and configuration information. With one centralized repository for user profiles, and one SDK, it’s possible for multiple services or applications to leverage the same user data.
Attribute TypesThe attributes that make up an Identity Server service are classified as one of the following types: Dynamic, Policy, User, Organization or Global. Using these types to subdivide the attributes in each service allows for a more consistent arrangement of the service schema and easier management of the service parameters.
Dynamic Attributes
A dynamic attribute can be assigned to an Identity Server configured role or organization. When the role is assigned to a user or a user is created in an organization, the dynamic attribute then becomes a characteristic of the user. For example, a role is created for an organization’s employees. This role might contain the organization’s address and a fax number, two things that remain static for all employees. When the role is assigned to each employee, these dynamic attributes are inherited by each employee.
User Attributes
These attributes are assigned directly to each user. They are not inherited from a role or an organization and, typically, are different for each user. Examples of user attributes include userid, employee number and password. User attributes can be added or removed from the User service by modifying the amUser.xml file. For more information, see the Sun One Identity Server Programmer’s Guide.
Organization Attributes
Organization attributes are only assigned to organizations. No object classes are associated with organization attributes. Attributes listed in the authentication services are defined as organization attributes because authentication is done at the organization level rather than at a subtree or user level.
Global Attributes
Global attributes are applied across the Identity Server configuration. They cannot be applied to users, roles or organizations as the goal of global attributes is to customize the Identity Server application. There is only one instance of a global attribute in the Identity Server configuration. There are no object classes associated with global attributes. Examples of global attributes include log file size, log file location, port number or a server URL that Identity Server can use to access data.
Policy Attributes
Policy attributes specify the access control actions (or privileges) associated with a service. They become a part of the rules when rules are added to a policy. Examples include canForwardEmailAddress and canChangeSalaryInformation. The actions specified by these attributes can be associated with a specific resource. See Policy Framework for related information.
Identity Server Core ServicesDefault services are provided with Identity Server and are defined by XML files located in the following directory:
/etc/opt/SUNWam/config/xml
Some of these services, when configured through the Service Configuration interface, define values that are applied across the Identity Server application. Others are registered to a specific organization configured within Identity Server and are used to define default values for the organization.
Administration
The Administration service allows for the configuration of the console at both the application level (similar to a Preferences or Options menu for the Identity Server application) as well as at a configured organization level (Preferences or Options specific to a configured organization).
Authentication
There are a number of Identity Server authentication modules including a base module. This allows the administrator the opportunity to choose the method each defined organization uses to verify users’ identities.
This module allows for log in without specifying a user name and password. Anonymous connections have limited access to the server and are customized by the administrator.
This module allows a user to log in through a personal digital certificate (PDC). The module comes with an Online Certificate Status Protocol (OCSP) which can determine the state of a certificate.
This module is the general configuration base for the Identity Server authentication services. It must be registered and configured to use any of the specific services. It allows the administrator to define default values that will be picked up for those not specifically set in the Anonymous, Certificate-based, HTTPBasic, LDAP, Membership, RADIUS, SafeWord, SecurID, Windows, and Unix services.
This module uses basic authentication, which is the HTTP protocol’s built-in authentication support. The Webserver issues a client request for username and password, and sends that information back to the server as part of the authorized request. Identity Server retrieves the username and password and then internally authenticates the user to the LDAP authentication module. The HTTPBasic module internally initializes the LDAP authentication module attributes. In order for HTTPBasic to function correctly, the LDAP authentication module must be configured (registering the HTTPBasic module alone will not work).
Kerberos. This module allows a client or user who has already authenticated by a Kerberos Distribution Center (KDC) to be authenticated by Identity Server without having to provide the login information again. This is also known as desktop single sign-on.
This module allows for authentication using LDAP bind, an operation which associates a password with a particular LDAP entry.
Membership (Self-Registration).
This module allows a new user to self-register for authentication with a login and password.
This module allows for authenticating users using a Windows 2000™ server.
This module allows for authenticating users using an external Remote Authentication Dial-In User Service (RADIUS) server.
This module allows for authenticating users using Secure Computing’s SafeWord™ or SafeWord PremierAccess™ authentication servers.
This module allows for authenticating users using RSA’s ACE/Server authentication server. Note that SecurID is not supported on the Solaris x86 platform.
This module allows for authenticating users using the Identity Server UNIX service. Note that UNIX authentication service is not supported on the Windows 2000 platform.
Authentication Configuration
The Authentication Configuration service allows you to configure authentication on for roles, users and services and organizations to set the rules determining the precedence of the authentication modules.
Client Detection
The Client Detection service defines attributes to detect the type of client being used, and performs actions based on client type.
Logging
The Logging service provides status and error messages related to Identity Server administration. An administrator can configures values such as log file size and log file location. Identity Server can record events in flat text files or in a relational database.
Naming
The Naming service is used to get and set URLs, plug-ins and configurations as well as request notifications for various other Identity Server services such as session, authentication and logging.
Password Reset
Identity Server provides a Password Reset service to allow users to receive via email a new password, or to reset their password, for access to a given service or application protected by Identity Server.
Platform
The Platform service is where additional servers can be added to the Identity Server configuration as well as other options applied at the top level of the Identity Server application.
Policy Configuration
Policy Configuration defines user privileges to web resources, allowing an administrator to allow or deny access to http and https-based URLs.
SAML
The Security Assertion Markup Language (SAML) service defines a framework for exchanging security assertions among security authorities. This makes interoperability across different platforms possible, enabling authentication and authorization, and attribute services.
Session
The Session service defines values for an authenticated user session such as maximum session time and maximum idle time.
User
Default user preferences are defined through the user service. (These include time zone, locale and DN starting view).
The Service Configuration InterfaceServices are configured and managed through the Service Configuration module. Organization-specific services which are not covered by the Identity Server default service packages can be written using XML (based on the Identity Server services document type definition or DTD) and added into the interface under the Other Configuration heading.
The Service Configuration module is for displaying service configurations on a global level. In other words, it is a view of the default configurations of all available services in Identity Server, whether registered or not. When a service is registered and activated by an organization, the initial default data assigned to the service is displayed under the service’s Service Configuration page. Figure 4-1 is a screenshot of the graphical user interface.
Figure 4-1 Service Configuration View
