Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Access Manager 6 2005Q1 Developer's Guide 

Chapter 8
Service Management

Sun Java™ System Access Manager 6 2005Q1 provides a mechanism for the definition and management of services and their configuration data. Both eXtensible Markup Language (XML) files and Java™ interfaces are used for this purpose. This chapter provides information on how to define a service, the structure of the XML files and the service management application programming interfaces (API). It contains the following sections:

Overview

A service is a group of attributes that are managed together by the Access Manager console. The attributes can be the configuration parameters of a software module or they might just be related information with no connection to a software application. As an example of the first scenario, after creating a payroll module, a developer can create an XML service file that might include attributes to define an employee name, an hourly pay rate and an income tax rate. This XML file is then integrated into the Access Manager deployment so that these three attributes and their corresponding values can be stored in, and managed from, the Sun Java System Directory Server data store and Access Manager console, respectively.

Access Manager provides the necessary tools for administrators to define, integrate and manage groups of attributes as a service. Creating a service for management using the Access Manager console involves preparing an XML service file, configuring an LDAP Data Interchange Format (LDIF) file with any new object classes and importing both, the XML service file and the new LDIF schema, into the Directory Server. Administrators can then register, customize and manage the service using the Access Manager console. More specific information on this process can be found in Defining A Custom Service.

Note

Throughout this chapter, the term attribute is used to illustrate two concepts. An Access Manager or service attribute refers to the configuration parameters of a defined service. An XML attribute refers to the parameters that qualify an XML element in an XML service file.

XML Service Files

XML service files enable Access Manager to manage attributes that are stored in Directory Server. It is important to remember that Access Manager does not implement any behavior or dynamically generate any code to interpret the attributes; it can only set or get the attribute values. Out-of-the-box though, Access Manager loads a number of services it uses to manage the attributes of its own features; it manages and uses these values. For example, the Logging attributes are displayed and managed in the Access Manager console, while code implementations within the Access Manager use these configured attributes to record the operations of the application. All XML service files are located in /etc/opt/SUNWam/config/xml. For more specific information on the XML files used in service management, see XML Service Files.

Note

Any application with LDAP attributes can have its data managed using the Access Manager console by configuring a custom XML service file and loading it into the Directory Server. For more information, see Defining A Custom Service.

Document Type Definition Structure Files

The format of an XML file is based on a structure defined in a DTD file. In general, a DTD file defines the elements and qualifying attributes needed to write a well-formed and valid XML document. Access Manager exposes the DTD files that are used to define the structure for the different types of XML files it uses. The DTDs are located in IdentityServer_base/SUNWam/dtd. This chapter primarily concerns itself with sms.dtd, the file that defines the structure for all XML service files. Additional information on Access Manager DTDs can be found in DTD Files.

Note

Knowledge of XML is necessary to understand DTD elements and how they are integrated into Access Manager. When creating an XML file, it might be helpful to print out the relevant DTD and a corresponding sample XML file.

Service Management SDK

Access Manager also provides a service management SDK that gives application developers the interfaces necessary to register and un-register services as well as manage schema and configuration information. These interfaces are bundled in a package called com.sun.identity.sm. More information on the SDK can be found in Service Management SDK.

Defining A Custom Service

To define a service for management using Access Manager, the developer must create an XML service file as well as configure an LDIF file for any object classes not already defined in Directory Server. Both, the XML service file and the new LDIF schema, must then be imported into Directory Server. Once imported, the service can be registered to an organization using Access Manager and its attributes managed and customized by the Access Manager administrator. The following steps detail the procedure used to define a service. The sections following the procedure explain each step in more detail.

  1. Create an XML service file containing a group of attributes.

    2. This XML service file must conform to the sms.dtd. A simple way to create a new XML service file would be to copy and modify an existing one. More information on creating an XML service file can be found in Creating A Service File. An explanation of the DTD syntax can be found in The sms.dtd Structure.

  2. Extend the LDAP schema in Directory Server using ldapmodify, if necessary.

    3. Loading an LDIF file into Directory Server will add any newly defined or modified LDAP object classes and attributes to the directory tree. This step is only necessary when defining dynamic, policy and user attributes. (Using Access Manager-specific object classes and attributes do not require that changes be made to the LDAP schema.) Instructions on extending the LDAP schema can be found in Extending The Directory Server Schema. Additional information on identity-related objects and the Access Manager schema can be found in Chapter 7, "Identity Management," of this manual and the Sun Java System Access Manager Deployment Planning Guide, respectively. The Sun Java System Directory Server documentation contains information on the LDAP schema.

  3. Import the XML service file into Directory Server using amadmin.

    4. Information on importing an XML service file and the amadmin command line utility can be found in Importing The XML Service File and the Sun Java System Access Manager Administration Guide, respectively.

  4. Configure a localization properties file and copy it into the IdentityServer_base/SUNWam/locale directory.

    5. The localization properties file must be created with accurate i18nKey fields. These console names map to fields defined in the XML service file. If no localization properties file exists, Access Manager will display the actual attribute names. More information on the localization properties file can be found in Configuring Console Localization Properties and Localization Properties Files of Chapter 5, "Authentication Service," in this manual.

  5. Update the amEntrySpecific.xml or amUser.xml files, if necessary.

    6. The amEntrySpecific.xml file defines the attributes that will display on the Create, Properties and Search pages specific to each of the Access Manager abstract objects. The amUser.xml file can be modified to add User attributes to the User Service. (Alternately, User attributes can be defined in the actual XML service file in which case, amUser.xml would not need to be modified.) Information on abstract objects and updating amEntrySpecific.xml can be found in Chapter 7, "Identity Management," of this manual. Information on modifying amUser.xml can be found in Modifying A Default XML Service File.

  6. Register the service using Access Manager console.

    7. After importing the service into Directory Server, it can be registered to an organization and the attributes managed through the Access Manager console. Information on how this can be done is in the Service Configuration chapter in the Sun Java System Access Manager Administration Guide. Information on how to register the service using the command line can be found in Registering The Service.

Creating A Service File

The information in this section corresponds to Step 1, creating an XML service file. The XML service file defines the attributes of an Access Manager service. It must follow the structure defined in the sms.dtd which enforces the service developer to combine attributes into one of five groups, allowing the developer to differentiate between those attributes applicable to, for example, a service instance or a user. The DTD syntax can be found in The sms.dtd Structure.

Service File Naming Conventions

When creating a new XML service file, there are some naming conventions that must be followed.

Service Attributes

The sms.dtd requires the service developer to define attributes into one of five groups. These groups differentiate between those attributes applicable to, for example, the Access Manager deployment as a whole, a specific service or a single user.

Global Attributes

Global attributes are defined for the entire Access Manager installation and are common to all data trees, service instances and integrated applications within the configuration. Global attributes can not be applied to users, roles or organizations as their purpose is to configure Access Manager itself. Server names, port numbers, service plug-ins, cache size, and maximum number of threads are examples of global attributes that are configured with one value. For example, when Access Manager performs logging functions, the log files are written into a directory. The location of this directory is defined as a global attribute in the Logging Service and all Access Manager logs, independent of their purpose, are written to it. Access Manager administrators can modify these default values using the console. Global attributes are stored in Directory Server using specially-defined LDAP attributes so the LDAP schema does not need to be extended to add a new global attribute.

Note

If a service has only global attributes, it can not be registered to an organization nor can a service template be created. An example of this would be the Platform Service.

Organization Attributes

Organization attributes are defined and assigned at the organization level. Attributes for an Authentication Service are a good example. When the Authentication Service is registered, attributes are configured depending on the organization to which it is registered. The LDAP Server and the DN To Start User Search would be defined at the organization level as this information is dependent on the address of an organization’s LDAP server and the structure of their directory tree, respectively. Organization attributes are stored in Directory Server using specially-defined LDAP attributes so the LDAP schema does not need to be extended to add a new organization attribute.

Note

Organization attributes are not inherited by sub-organizations. Only dynamic attributes can be inherited. For additional information, see Attribute Inheritance.

Dynamic Attributes

Dynamic attributes are inheritable attributes that work at the role and organization levels as well as the sub-organization and organizational unit levels. Services are assigned to organizations and roles which, in general, have access to any service assigned to its parent organization. Dynamic attributes are inherited by users that possess a role or belong to the organization. Because dynamic attributes are assigned to roles or organizations instead of set in a user entry, they are virtual attributes inherited by users using the concept of Class of Service (CoS). When these attributes change, the administrator only has to change them once, in the role or organization, instead of a multitude of times in each user entry.

Note

Dynamic attributes are modeled using class of service (CoS) and roles. For information on these features, see Appendix E, "Directory Server Concepts," in this manual or refer to the Sun Java System Directory Server documentation.

An example of a dynamic attribute might be the address of a common mail server. Typically, an entire building might have one mail server so each user would have a mail server attribute in their entry. If the mail server changed, every mail server attribute would have to be updated. If the attribute was in a role that each user in the building possessed, only the attribute in the role would need to be updated. Another example might be the organization’s address. Dynamic attributes are stored within the Directory Server as LDAP objects, making it feasible to use traditional LDAP tools to manage them. A Directory Server LDAP schema needs to be defined for these attributes.

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 resource if the IsResourceNameAllowed element is specified in the attribute definition. For example, in the web agent XML service file, amWebAgent.xml, GET and POST are defined as policy attributes with an associated URL resource as IsResourceNameAllowed is specified.

Note

Out of the box, only the Policy Configuration Service uses policy attributes although they can be defined for any number of services.

User Attributes

User attributes are defined for a single user. User attributes are not inherited from the role, organization, or sub-organization levels. They are typically different for each user, and any changes to them would affect only the particular user. User attributes could be an office telephone number, a password or an employee ID. The values of these attributes would be set in the user entry and not in a role or organization. For example, if 70 attributes are user-defined and an organization has two million users, each attribute is stored two million times. This, of course, only occurs if the service is assigned to the user and a value is set for them. User attributes can be a part of any service but, for convenience, Access Manager has grouped a number of the most widely-used attributes into a service defined by the amUser.xml service file. User attributes are stored within the Directory Server as LDAP objects, making it feasible to use traditional LDAP tools to manage them. A Directory Server LDAP schema needs to be defined for these attributes.

Note

When defining user attributes in an XML service file (other than amUser.xml), the service must be assigned to the user for the user attributes to be displayed on their User Profile page. In addition, the User Profile Display Option in the Administration Service must be set to Combined. For more information, see the Sun Java System Access Manager Administration Guide.

Attribute Inheritance

After creating and loading an XML service file, an administrator can assign the service’s attributes by registering it and creating a service template. Then, when a user possesses a role or belongs to an organization to which the service is registered, they inherit the dynamic attributes of the role or the service, respectively. Inheritance only occurs, though, when the service possessed is explicitly assigned to the user. A user can inherit attributes from multiple roles or parent organizations.

Tip

Service templates created for a parent organization contain attributes that trickle down to sub-organizations. Therefore it is not necessary to create templates for sub-organizations unless the attribute values are being customized. Creating a large number of service templates will have a performance impact.

ContainerDefaultTemplateRole Attribute

Dynamic attributes are used in an XML service file if an administrator wants to define a particular attribute as one which is inherited by all identity objects to which the service is registered. After uploading the XML service file and registering the service to an organization or role, all users in the sub-trees of the organization or role will inherit the dynamic attributes. To accomplish this, Access Manager uses classic CoS and role templates (as described in Appendix E, "Directory Server Concepts"). ContainerDefaultTemplateRole is a default filtered role configured for each organization in which the LDAP object class iplanet-am-managed-person is the default filter. Every user in Access Manager is a member of iplanet-am-managed-person so every user in the organization possesses ContainerDefaultTemplateRole. Access Manager creates a separate CoS template for each registered service which points to the service’s dynamic attributes. Because of this, any user who has ContainerDefaultTemplateRole (all of them, by default) will inherit the dynamic attributes of the service. The LDIF entry for ContainerDefaultTemplateRole is illustrated in Code Example 8-1.

Code Example 8-1  ContainerDefaultTemplateRole LDIF Entry

dn: cn=ContainerDefaultTemplateRole,o=example

objectClass: top

objectClass: nscomplexroledefinition

objectClass: nsfilteredroledefinition

objectClass: nsroledefinition

objectClass: ldapsubentry

nsRoleFilter: (objectclass=iplanet-am-managed-person)

Modifying Inheritance

The nsRoleFilter attribute (as displayed in Code Example 8-1 may be modified to allow objects other than users to inherit from ContainerDefaultTemplateRole. Formatting its value as, for example, (|(objectclass=iplanet-am-managed-person)(objectclass=organization)) allows users and organizations to inherit the dynamic attributes. Any valid filter syntax can be used although typically it would be limited to attributes or objectclasses in the user entries. In addition, the relevant objectclass from the LDAP attributes must also be added to the entry.

Extending The Directory Server Schema

The information in this section corresponds to Step 2, extending the LDAP schema in Directory Server. When configuring an XML service file for Access Manager, it might also be necessary to modify the Directory Server schema. First, any customized dynamic, policy or user attributes defined in an Access Manager service that are not already defined in the Directory Server schema need to be associated with an LDAP object class. Then the attribute(s) and object class(es) need to be added to the LDAP schema using the ldapmodify command line tool and an LDIF file as input.

Note

The order in which the LDAP schema is extended or the XML service file is loaded into Directory Server is not important.

To Extend The Directory Server LDAP Schema

  1. Create an LDIF file to define any new or modified LDAP object classes and attributes.
  2. Change to the Access Manager bin directory.

    3. cd IdentityServer_base/SUNWam/bin

  3. Run ldapmodify using the LDIF file as input.

    4. The syntax is ldapmodify -D userid_of_DSmanager -w password -f path_to_LDIF_file. By default, userid_of_DSmanager is cn=Directory Manager. If the LDIF was created correctly, the result of this command would be to modify the entry cn=schema.

    Note

    After extending the schema, it is not necessary to restart the Directory Server but, as ldapmodify is server-specific, the schema needs to be extended on all configured servers. Information on how this is done can be found in the Sun Java System Directory Server documentation.

  4. Run ldapsearch to ensure that the schema has been created.

    5. The syntax is ldapsearch -b cn=schema -s base -D userid_of_DSmanager -w password (objectclass=*) | grep -i servicename. If the LDIF was created correctly, the result of this command would be a listing of the object classes as illustrated in Code Example 8-2.

    Code Example 8-2  Sample LDIF Listing For Mail Service

    objectClasses: ( 1.2.NEW

    NAME 'am-sample-mail-service'

    DESC 'SampleMail Service' SUP top AUXILIARY

    MAY ( am-sample-mail-service-status $

    am-sample-mail-root-folder $

    am-sample-mail-sentmessages-folder $

    am-sample-mail-indent-prefix $

    am-sample-mail-initial-headers $

    am-sample-mail-inactivity-interval $

    am-sample-mail-auto-load $

    am-sample-mail-headers-perpage $

    am-sample-mail-quota $

    am-sample-mail-max-attach-len $

    am-sample-mail-can-save-address-book-on-server )

    X-ORIGIN ’user defined’ )

    attributeTypes: ( 11.24.1.996.1

    NAME ’am-sample-mail-service-status’

    DESC ’SampleMailService Attribute’

    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

    X-ORIGIN ’user defined’ )

Adding Access Manager Object Classes To Existing Users

If a new service is created and the service’s users already exist, the service’s object classes need to be added to the user’s LDAP entries. To do this, Access Manager provides migration scripts for performing batch updates to already-existing user entries. No LDIF file need be created. These scripts and the procedures are described in the Sun Java System Access Manager Migration Guide. Alternatively, registered services can be added to each user by selecting the service on their Properties page although, for an organization with many users, this would be time-consuming.

Caution

It is not recommended to use ldapmodify to extend the schema.

Importing The XML Service File

The information in this section corresponds to Step 3, importing an XML service file into Access Manager. This step is important as it serves to populate Directory Server and Access Manager with the newly defined service attributes.

  1. Change to the Access Manager install directory:

    2. cd IdentityServer_base/SUNWam/bin

  2. Run following command line application: ./amadmin --runasdn DN_of_directory_server_administrator --password password_directory_server_administrator --verbose --schema xml_service_file_path.

    3. More information on the amadmin command line tool can be found in the Sun Java System Access Manager Administration Guide

    Note

    If changing an existing service, the original XML service file must be deleted before importing the newly modified XML service file. Information on this function can be found in the Sun Java System Directory Server documentation.

Configuring Console Localization Properties

The information in this section corresponds to Step 4, configuring a localization properties file. A localization properties file specifies the locale-specific screen text that an administrator or user will see when directed to a service’s attribute configuration page.

Note

For certain services, this file also localizes error messages, Java exceptions and email notification specifics. This section though concerns itself only with service-related values. Additional information can be found in Localization Properties Files of Chapter 5, "Authentication Service," in this manual.

The localization properties files are located in the IdentityServer_base/SUNWam/locale directory. They are generally named using the format amservice_name.properties. Code Example 8-3 is the localization properties file for the Client Detection service named amClientDetection.properties.

Code Example 8-3  amClientDetection.Properties File 

...

# attr descriptions msgs

#

iplanet-am-client-detection-service-description=Client Detection

a100=Client Types

a101=Default Client Type

a102=Client Detection Class

a103=Client Detection Enabled

a100.link=Edit

unknown_key=requested key is not available in the property

null_key=null key passed to getProperty

null_clientType=client type is null

unknown_clientType=requested clientType doesn't exist

update_error=notification received between setproperty and store. Need to do

setproperty again.

The localization properties files consist of a series of key=value pairs. The value of each pair will be displayed on the service’s Properties page in the Access Manager console. The keys (a1, a2, etc.) map to the i18nKey fields defined for each attribute in a service in the XML service file. The keys also determine the order in which the fields are displayed on screen as the keys are displayed in the order of their ASCII characters (a1 is followed by a10, followed by a2, followed by b1). For example, if an attribute needs to be displayed at the top of the service attribute page, the alphanumeric key should have a value of a1. The second attribute could then have a value of either a10, a2 or b1, and so forth.

Tip

If a localization properties file is modified, Access Manager needs to be restarted to see the changes. If importing a new localization properties file, Access Manager does not need to be restarted.

Localizing With Two Languages

When one instance of Access Manager is localized with two languages, the localization properties files still go into the same directory. Each file name would be appended with a suffix to match the locale. For example, if French localization packages are added, the file name would be amservice_name_fr.properties. If Spanish localization packages are added, that properties file name would be amservice_name_es.properties.

Note

Information on downloading and installing localized versions of Access Manager can be found at http://wwws.sun.com/software/download/ inter_ecom.html.

Updating Files For Abstract Objects

For information corresponding to Step 5, updating the amEntrySpecific.xml, see Chapter 7, "Identity Management," of this manual. For information corresponding to Step 5, updating the amUser.xml, see XML Service Files.

Registering The Service

The information in this section corresponds to Step 6, registering a new service to an identity object. The preferred way to register a service is to use the Access Manager console. Information on how this is done can be found in the Sun Java System Access Manager Administration Guide. An alternate process to register a service is to use the amAdmin.dtd, batch processing templates and the command line. Information can be found in The amAdmin.dtd Structure and Batch Processing With XML Templates.

Note

To register a service, ensure that Access Manager is properly binding to the Directory Server.

DTD Files

Access Manager contains numerous DTD files to define the structures for the XML files used in Access Manager. The DTDs are located in IdentityServer_base/SUNWam/dtd and include:

The sms.dtd Structure

The sms.dtd defines the data structure for all XML service files. It is located in the IdentityServer_base/SUNWam/dtd directory. The sms.dtd enforces the developer to define each service attribute as one of five types which are then stored and managed differently. For instance, some of the attributes are applicable to an entire Access Manager installation (such as a port number or server name), while others are applicable only to individual users (such as a password). The attribute types are Global, Organization, Dynamic, Policy, and User. More information on these types can be found in Service Attributes.

An explanation of the main elements defined by the sms.dtd follows. Each element includes a number of XML attributes which are also explained. Explanations of the remaining elements can be found in the sms.dtd file itself. Access Manager currently supports only about some of the elements contained in sms.dtd; this section discusses only those elements.

Note

Customized attribute names in XML service files should be written in lower case as Access Manager converts all attribute names to lower case when reading from the Directory Server.

ServicesConfiguration Element

ServicesConfiguration is the root element of the XML service file. It allows for the definition of multiple services per one XML file. Its immediate sub-element is the Service Element. Code Example 8-4 illustrates the ServicesConfiguration element as defined in the amClientDetection.xml service file located in /etc/opt/SUNWam/config/xml.

Code Example 8-4  ServicesConfiguration and Service Element

...

<ServicesConfiguration>

<Service name=”iPlanetAMClientDetection” version=”1.0”>

<Schema...>

...

Service Element

The Service element defines the schema for one given service. A number of different services can be defined in one XML file using this element, although this is not recommended. Currently, Access Manager supports the following sub-elements: Schema Element (which defines the service’s attributes as either Global, Organization, Dynamic, User or Policy) and Configuration. The required XML attributes for the Service element are the name of the service, such as iPlanetAMLogging, and the version number of the XML service file itself. Code Example 8-4 also illustrates the Service element, its attributes and the opening Schema tag.

Schema Element

The Schema element is the parent of the family of elements that define the service’s attributes and their default values. The sub-elements can be the Global Element, Organization Element, Dynamic Element, User Element or Policy Element. The required XML attributes of the Schema element include the serviceHierarchy Attribute, the i18nFileName Attribute, the i18nKey Attribute, and the propertiesViewBeanURL Attribute.

serviceHierarchy Attribute

When a new service is configured, its name will be dynamically displayed in the Navigation frame of the console based on the value of this attribute. The value is a "/" separated string. Each "/" portion of the string represents a level in the hierarchy. Code Example 8-5 illustrates the serviceHierarchy attribute as defined in amClientDetection.xml. iPlanetAMClientDetection is the name of the service. The name used for display in the console, though, is defined by the i18nKey (or i18nKey Attribute), and retrieved from the service’s localization file defined by the i18nFileName Attribute. In this example, the value of iplanet-am-client-detection-service-description will be found in amClientDetection.properties and its value displayed. The service name will be displayed below the Access Manager Configuration header in the left frame of the Service Configuration module. To prevent a service from displaying in the console, either remove the serviceHierarchy attribute or set it’s value to "", as in serviceHierarchy="".

Note

DSAMEConfig as used in Code Example 8-5 and all XML service files refers to the Access Manager Configuration header. The use of DSAME is a holdover from the previous name of Access Manager. This is defined in the amAdminModuleMsgs.properties file located in IdentityServer_base/SUNWam/locale.

Code Example 8-5  i18nFileName, i18nKey and serviceHierarchy Attributes 

...

<Schema

serviceHierarchy="/DSAMEConfig/iPlanetAMClientDetection"

i18nFileName="amClientDetection"

i18nKey="iplanet-am-client-detection-service-description">

...

i18nFileName Attribute

The i18nFileName attribute refers to the localization properties files. It takes a value equal to the name of the localization properties file for the defined service (minus the .properties file extension). For example, Code Example 8-5 defines the name of the properties file as amClientDetection.

i18nKey Attribute

The value of the %i18nIndex attribute maps to the final, localized name of the service to be displayed in the Access Manager console as it is defined in the localization properties file.

Note

The %i18nIndex attribute is defined as an entity at the top of the sms.dtd. In the configured XML service files, %i18nIndex is replaced by i18nKey and its corresponding value.

For example, Code Example 8-5 refers to the value of the iplanet-am-client-detection-service-description attribute as defined in amClientDetection.properties. This value is the name of the service as it will be displayed in the Access Manager console; in this case, Client Detection is the name defined in amClientDetection.properties. (Remember, the value of the defined attribute might not be in English.) More information on the localization properties file can be found in Chapter 5, "Authentication Service," of this manual.

Note

If the i18nKey value is blank (i18nKey=""), the Access Manager console will not display the attribute.

propertiesViewBeanURL Attribute

The default display for a service is a simple table showing the attribute name and its value. The propertiesViewBeanURL attribute provides the URL to the Java bean used by the console to generate this display. It is possible to override the default display by creating a new class and defining the URL to this class as a value of this attribute. If no value is specified, the display is created by the console.

Service Attribute Elements

The next five elements are sub-elements of the Schema Element; they are the declarations of the service’s Access Manager attributes. When defining a service, each attribute must be defined as either a Global Element, an Organization Element, a Dynamic Element, a User Element, or a Policy Element. Any configuration of these elements (all of them or none of them) can be used depending on the service. Each attribute defined within these elements is itself defined by an AttributeSchema Element.

Global Element

The Global element defines Access Manager attributes that are modifiable on a platform-wide basis and applicable to all instances of the service in which they are defined. They can define information such as port number, cache size, or number of threads, but Global elements also define a service’s LDAP object classes. For additional information, see Global Attributes.

serviceObjectClasses Attribute    

The serviceObjectClasses attribute is a global attribute defined in an XML service file that contains either dynamic or user elements (attributes). The value of this attribute is an object class set in the LDAP entries (stored in Directory Server) for users whom are registered to the service. It allows any user with this object class to be dynamically assigned the service’s dynamic or user attributes, if any exist.

Caution

If the serviceObjectClasses attribute is not specified and the service has defined dynamic or user attributes, an object class violation is called when an administrator tries to create a user under that organization, and assign this service.

Multiple values can be defined for the serviceObjectClasses attribute. For example, if a service is created with two attributes each from three other services, the serviceObjectClasses attribute would need to list all three object classes as DefaultValues. Code Example 8-6 illustrates a serviceObjectClasses attribute with a defined object class from amClientDetection.xml.

Code Example 8-6  serviceObjectClass Defined As Global Element

...

<Global>

<AttributeSchema name="serviceObjectClasses"

type="list"

syntax="string"

i18nKey="">

<DefaultValues>

<Value>iplanet-am-client-detection-service</Value>

</DefaultValues>

</AttributeSchema>

</Global>

...

Organization Element

The Organization element defines Access Manager attributes that are modifiable per organization or sub-organization. For example, a web hosting environment using Access Manager would have different configuration data defined for each organization it hosts. A service developer would define different values for each organization attribute per organization. These attributes are only accessible using the Access Manager SDK. For additional information, see Organization Attributes.

Dynamic Element

The Dynamic element defines Access Manager attributes that can be inherited by all user objects. Examples of Dynamic elements would be user-specific session attributes, a building number, or a company mailing address. Dynamic attributes use the Directory Server features, CoS and roles. For additional information, see Dynamic Attributes.

User Element

The User element defines Access Manager attributes that exist physically in the user entry. User attributes are not inherited by roles or organizations. Examples include password and employee identification number. They are applied to a specific user only. For additional information, see User Attributes.

Policy Element

The Policy element defines Access Manager attributes intended to provide actions (or privileges). This is the only attribute element that uses the ActionSchema element to define its parameters as opposed to the AttributeSchema element. Generally, privileges are GET, POST, and PUT; examples of privileges might include canChangeSalaryInformation and canForwardEmailAddress. For additional information, see Policy Attributes.

SubSchema Element

The SubSchema element can specify multiple sub-schemas of global information for different defined applications. For example, logging for a calendar application could be separated from logging for a mail service application. The required XML attributes of the SubSchema element include name which defines the name of the sub-schema, inheritance which defines whether this schema can be inherited by one or more nodes on the directory tree, maintainPriority which defines whether priority is to be honored among its peer elements, and i18nKey Attribute.

Note

The SubSchema element is used only in the amEntrySpecific.xml file. It should not be used in any external XML service files.

AttributeSchema Element

The AttributeSchema element is a sub-element of the five schema elements discussed in Service Attribute Elements as well as the SubSchema element described in SubSchema Element. It defines the structure for each configurable parameter (or attribute) of a service. The sub-elements that qualify the AttributeSchema can include IsOptional?, IsServiceIdentifier?, IsResourceNameAllowed?, IsStatusAttribute?, ChoiceValues?, BooleanValues?, DefaultValues?, or Condition. The XML attributes that define each portion of the attribute value are the name Attribute, the type Attribute, the uitype Attribute, the syntax Attribute, the cosQualifier Attribute, rangeStart, rangeEnd, minValue, maxValue, validator, the any Attribute, the propertiesViewBeanURL Attribute and, the i18nKey Attribute. Code Example 8-7 illustrates an AttributeSchema element taken from amUser.xml, its attributes and their corresponding values. Note that this example attribute is a Dynamic attribute.

Code Example 8-7  AttributeSchema Element With Attributes 

...

<Dynamic>

<AttributeSchema name="iplanet-am-user-login-status"

type="single_choice"

syntax="string"

any="display"

i18nKey="d105">

<ChoiceValues>

<ChoiceValue i18nKey="u200">Active</ChoiceValue>

<ChoiceValue i18nKey="u200">Inactive</ChoiceValue>

</ChoiceValues>

<DefaultValues>

<Value>Active</Value>

</DefaultValues>

</AttributeSchema>

...

name Attribute

This required XML attribute defines the a name for the attribute. Any string format can be used but attribute names must be in lower-case. Code Example 8-7 defines it with a value of iplanet-am-user-login-status.

type Attribute

This attribute specifies the kind of value the attribute will take. The default value for type is list but it can be defined as any one of the following:

ChoiceValues Sub-Element    

If the type attribute is specified as either single_choice or multiple_choice, the ChoiceValues sub-element must also be defined in the AttributeSchema element. Depending on the type specified, the administrator or user would choose either one or more values from the choices defined. The possible choices are defined in the ChoiceValues sub-element, ChoiceValue. Code Example 8-7 defines the type as single_choice; the ChoiceValues attribute defines the list of options as Active and Inactive with the DefaultValue as Active.

syntax Attribute

The syntax attribute defines the format of the value. The default value for syntax is string but, it can be defined as any one of the following:

uitype Attribute

This attribute specifies the HTML element that will be displayed in the Access Manager console. Possible values include radio, link, button, or name_value_list. No value defined for this attribute displays a default element based on the information in Table 3-1 of Chapter 3, "The Access Manager Console."

Note

The type Attributespecifies the kind of value an attribute will take. The syntax Attribute defines the format of that value. The uitype Attribute specifies the HTML element. The values of these attributes can be mixed and matched to alter the console display. See To Change The Default Attribute Display Elements of Chapter 3, "The Access Manager Console," in this manual for information on how these attributes work together.

DefaultValues Sub-Element    

Defining a syntax might also necessitate defining a value for the DefaultValue sub-element. A default value will then be displayed in the Access Manager console; this default value can be changed for each organization when creating a new template for the service.

Caution

Default values of User attributes are not inherited by users when the service is assigned using the Access Manager console.

For example, all instances of the LDAP Authentication Service use the port attribute so a default value of 389 is defined in the XML service file. Once registered, this value can be modified for each organization using the Access Manager console. (The default value is also used by integrated applications when a service template has not been registered to an organization.) Code Example 8-8 from amAuthLDAP.xml illustrates this scenario.

Code Example 8-8  DefaultValues In amAuthLDAP.xml

...

<Organization>

<AttributeSchema name="iplanet-am-auth-ldap-server"

type="list"

syntax="string"

i18nKey="a101">

<DefaultValues>

<Value>identity_server_host.com:389</Value>

</DefaultValues>

</AttributeSchema>

...

cosQualifier Attribute

This attribute defines how Access Manager resolves conflicting dynamic attribute values assigned to the same user object. The value of cosQualifier will appear as a qualifier to the cosAttribute in the LDAP entry of the CoS definition.

Note

The priority level is defined by the Conflict Resolution Level attribute. More information on this attribute can be found in the Sun Java System Access Manager Administration Guide.

The value of cosQualifier can be defined as:

If the cosQualifier attribute is not defined, the default behavior is for the user entry value to override the CoS value in the organization or role. The default value is default. (The operational value is reserved for future use.)

any Attribute

The any attribute specifies whether the attribute for which it is defined will display in the Access Manager console. It has six possible values that can be multiply defined using the “|” (pipe) construct:

The required or optional keywords and the filter and display keyword can be specified with a pipe symbol separating the options (any=required|display or any=optional|display|filter). If the any attribute is set to display, the qualified attribute will display in Access Manager console when the properties for the Create page are displayed. If the any attribute is set to required, an asterisk will display in that attribute’s field, thus the administrator or user is required to enter a value for the object to be created in Access Manager console. If the any attribute is set to optional, it will display on the Create page, but users are not required to enter a value in order for the object to be created. If the any attribute is set to filter, the qualified attribute will display as a criteria attribute when Search is clicked from the User page.

Note

Setting the any attribute to "" (any="") will prevent the attribute to which it refers from being displayed in the console.

The amAdmin.dtd Structure

The amAdmin.dtd defines the data structure for an XML file which can be used to perform batch operations on the directory tree using the amAdmin command line tool. The file reflects the structure of the Access Manager SDK and is located in the IdentityServer_base/SUNWam/dtd directory. Possible command line operations include reads and gets on the attributes as well as creations and deletions of Access Manager objects (roles, organizations, users, people containers, and groups).

Note

XML files that are created based on the amAdmin.dtd are used as input with the amAdmin command line tool. More information on this tool can be found in the Sun Java System Access Manager Administration Guide.

The following sections explain the elements and attributes of the amAdmin.dtd using the sample XML templates installed with Access Manager for illustration. These samples can be found in IdentityServer_base/SUNWam/samples/admin/cli/bulk-ops.

Requests Element

The Requests element is the root element of the XML file. It must contain at least one sub-element to define the object(s) (Organization, Container, People Container, Role and/or Group, et. al.) upon which the configured actions can be performed. The Requests element must contain at least one of the following sub-elements:

To enable batch processing, the root element can take more than one of these sub-element requests.

Caution

If multiple sub-elements are specified, they must occur in the order in which they appear in the amAdmin.dtd. For example, a CreateUser cannot come before a CreateRole in the same OrganizationRequests element.

Code Example 8-9 illustrates the Requests element tag and its corresponding OrganizationRequests sub-element which details the creation of two roles, two groups, a suborganization, a container, and a people container in the organization with the LDAP Distinguished Name (DN), dc=example,dc=com.

Code Example 8-9  Portion Of createRequests.xml

...

<Requests>

<OrganizationRequests DN="dc=example,dc=com">

<CreateSubOrganization createDN="SubOrg1"/>

<CreateContainer createDN="Container1"/>

<CreatePeopleContainer createDN="People2"/>

<CreateRole createDN="ManagerRole"/>

<CreateRole createDN="EmployeeRole"/>

<CreateGroup createDN="ContractorsGroup"/>

<CreateGroup createDN="EmployeesGroup"/>

</OrganizationRequests>

...

OrganizationRequests Element

The OrganizationRequests element defines actions that can be performed on Organization objects. The required XML attribute for this element is the LDAP DN of the organization on which the configured requests will be performed. This element can have one or more sub-elements. (Different OrganizationRequests elements can be defined in one file to modify more than one organization.) Code Example 8-9 defines a myriad of objects to be created under the top level organization, dc=example,dc=com. The sub-elements of OrganizationRequests include:

ContainerRequests Element

The ContainerRequests element defines actions that can be performed on Container objects. The required XML attribute for this element is the LDAP DN of the container on which the configured requests will be performed. This element can have one or more sub-elements. (Different ContainerRequests elements can be defined in one file to modify more than one container.) The syntax for this element is basically the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of ContainerRequests can include:

PeopleContainerRequests Element

The PeopleContainerRequests element defines actions that can be performed on People Container objects. The required XML attribute for this element is the LDAP DN of the people container on which the configured requests will be performed. This element can have one or more sub-elements. (Different PeopleContainerRequests elements can be defined in one document to modify more than one people container.) The syntax for this element is basically the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of PeopleContainerRequests can include:

RoleRequests Element

The RoleRequests element defines actions that can be performed on roles. The required XML attribute for this element is the LDAP DN of the role on which the configured requests will be performed. This element can have one or more sub-elements. (Different RoleRequests elements can be defined in one document to modify more than one role.) The syntax for this element is the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of RoleRequests can include:

GroupRequests Element

The GroupRequests element defines actions that can be performed on Group objects. The required XML attribute for this element is the LDAP DN of the group on which the configured requests will be performed. This element can have one or more sub-elements. (Different GroupRequests elements can be defined in one document to modify more than one group.) The syntax for this element is the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of GroupRequests can include:

UserRequests Element

The UserRequests element defines actions that can be performed on User objects. The required XML attribute for this element is the LDAP DN of the user on which the configured requests will be performed. This element can have one or more sub-elements. (Different UserRequests elements can be defined in one document to modify more than one user.) The syntax for this element is the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of UserRequests can include:

ServiceConfigurationRequests Element

The ServiceConfigurationRequests element defines actions that can be performed on a specific service. The required XML attribute for this element is serviceName; it specifies the service on which the configured requests will be performed. This element can have one or more sub-elements. The syntax for this element is the same as that of the OrganizationRequests element illustrated in Code Example 8-9. The sub-elements of ServiceConfigurationRequests can include:

AddSubConfiguration Element

The AddSubConfiguration element adds a secondary schema to an existing service. The AttributeValuePair Element must be defined for each attribute configured in the subconfiguration. The required XML attributes are subConfigName, subConfigID, priority and serviceName.

Note

Attributes defined for a subconfiguration are validated against attributes defined in a subschema based on sms.dtd. A subconfiguration is defined for an organization, choosing from attributes globally defined in the subschema. For more information, see SubSchema Element.

DeleteSubConfiguration Element

The DeleteSubConfiguration element deletes an existing secondary schema from a service. The required XML attributes are subConfigName and serviceName which takes a string value.

DeleteAllServiceConfiguration Element

The DeleteAllServiceConfiguration element deletes all configurations relating to a service and removes them from the data store. The required XML attribute is userAtt which specifies whether to delete the user attributes related to the service.

AttributeValuePair Element

The AttributeValuePair element can be a sub-element of many of the batch processing requests. It can have two sub-elements, Attribute and Value, neither of which may have sub-elements. Code Example 8-10 illustrates that a sub-people container, ou=SubPeople2,ou=People2,dc=example,dc=com, and a user, dpUser, will be created with the attributes of the two objects defined as per the attribute/value pairs.

Attribute Element

The Attribute element must be paired with a Value element. The Attribute element itself contains no other elements. The required XML service attribute for the Attribute element is name which is equal to the name of the attribute that is being processed. Any string format can be used without spaces.

Value Element

The Value element defines the value of the Attribute element. More than one Value element can be specified for an Attribute. The Value element contains no other elements and it contains no XML service attributes.

Code Example 8-10  Another Portion Of createRequests.xml 

...

<PeopleContainerRequests DN="ou=People2,dc=example,dc=com">

<CreateSubPeopleContainer createDN="SubPeople2">

<AttributeValuePair>

<Attribute name="description"/>

<Value>SubPeople description</Value>

</AttributeValuePair>

</CreateSubPeopleContainer>

<CreateUser createDN="dpUser">

<AttributeValuePair>

<Attribute name="cn"/>

<Value>dpUser</Value>

</AttributeValuePair>

<AttributeValuePair>

<Attribute name="sn"/>

<Value>dpUser </Value>

</AttributeValuePair>

<AttributeValuePair>

<Attribute name="userPassword"/>

<Value>12345678</Value>

</AttributeValuePair>

</CreateUser>

...

CreateObject Elements

The CreateSubOrganization, CreateContainer, CreatePeopleContainer, CreateRole, CreateGroup, CreateServiceTemplate, CreateUser, CreateSubContainer, CreateSubGroup, CreateSubPeopleContainer elements create a sub-organization, container, people container, role, group, service template, user, sub-container, sub-group, and sub-people container, respectively. The object is created in the DN that is defined in the <Object>Requests element under which the particular Create<Object> element is being defined. AttributeValuePair Elements may be defined (or not). The required XML attribute for each element is createDN; it takes the DN of the object to be created. Code Example 8-10 illustrates an example of CreateSubPeopleContainer and CreateUser. The DN is defined in the PeopleContainerRequests element as ou=People2,dc=example,dc=com.

Note

CreateGroup/CreateSubGroup and CreateRole each have an additional attribute: groupType and roleType, respectively. groupType defines whether it is a static group, a filtered group or an assignable (dynamic) group. roleType defines whether it is a static role or a filtered role.

CreatePolicy Element

The CreatePolicy element creates one or more policy attributes. It takes the Policy element as a sub-element; createDN is the required XML attribute which takes the DN of the organization where the policy will be created. This and the following nested elements are illustrated in Code Example 8-11. This file is SamplePolicy.xml, part of the policy sample application located in IdentityServer_base/SUNWam/samples/policy.

Note

The following policy elements are the elements extracted from amAdmin.dtd for inclusion into the policy.dtd. More information can be found in the Access Manager Administration Guide.

Policy Element    

The Policy sub-element defines the permissions or rules of the policy and to whom/what the rule applies or the subject. It also defines whether or not the policy is a referral (delegated) policy and whether there are any restrictions (or conditions) to the policy. It may contain one or more of the following sub-elements: Rule, Conditions, Subjects, or Referrals. The required XML attributes are name which specifies the name of the policy and referralPolicy which identifies whether or not the policy is a delegated one.

Rule Element    

The Rule sub-element defines the specific permission of the policy and can take three sub-elements. The required XML attribute is name which defines a name for the rule. The three sub-elements are:

Subjects Element    

The Subjects sub-element identifies a collection of objects to which the policy applies; this overview collection is chosen based on membership in a group, ownership of a role or individual users. It takes the Subject sub-element. The XML attributes it can be defined with are name which defines a name for the collection, description which takes a description and includeType which defines whether the collection is as defined or its inverse (For example: the policy applies to users who are NOT members of the subject).

Subject Element    

The Subject sub-element identifies a collection of objects to which the policy applies; this collection pinpoints more specific objects from the collection defined by the Subjects element. Membership can be based on roles, group membership or simply a listing of individual users. It takes as a sub-element the AttributeValuePair Element. Its required XML attribute is type which identifies a generic collection of objects from which the specifically defined subjects are taken. Other XML attributes include name which defines a name for the collection and includeType which defines whether the collection is as defined or its inverse (For example: the policy applies to users who are NOT members of the subject).

Referrals Element    

The Referrals sub-element identifies a collection of policy assignments. It takes the Referral sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description. (Code Example 8-11 is not an example of a referral policy so there is not a Referrals element definition.)

Referral Element    

The Referral sub-element identifies a specific policy assignment. It takes as a sub-element the AttributeValuePair Element. Its required XML attribute is type which identifies a generic collection of assignments from which the specifically defined referrals are taken. It can also include the name attribute which defines a name for the collection. (Code Example 8-11 is not an example of a referral policy so there are no Referral elements definition.)

Conditions Element    

The Conditions sub-element identifies a collection of policy restrictions (time range, authentication level, et.al.). It must contain one or more of the Condition sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description.

Condition Element    

The Condition sub-element identifies a specific policy restriction (time range, authentication level, et.al.). It takes as a sub-element the AttributeValuePair Element. Its required XML attribute is type which identifies a generic collection of restrictions from which the specifically defined conditions are taken. It can also include the name attribute which defines a name for the collection.

Note

The Condition element might be used to configure policy for different URIs on the same domain. For example, http://org.example.com/hr can only be accessed by org.example.net from 9 am to 5 pm yet http://org.example.com/finance can be accessed by org.example2.net from 5 am to 11 pm. By defining an IP Condition attribute/value pair together with a SimpleTime Condition attribute/value pair and specifying http://org.example.com/hr/*.jsp as the resource, the policy would apply to all the JSPs under http://org.example.com/hr.

Code Example 8-11  SamplePolicy.xml 

<Requests>

<OrganizationRequests DN="dc=iplanet,dc=com">

<CreatePolicy createDN="dc=iplanet,dc=com">

  <Policy name="PolicyOne" referralPolicy="false" >

    <Rule name="dsdasd">

    <ServiceName name="SampleWebService" />

    <ResourceName name="http://www.sun.com/public" />

      <AttributeValuePair>

        <Attribute name="GET" />

        <Value>allow</Value>

      </AttributeValuePair>

      <AttributeValuePair>

        <Attribute name="DELETE" />

        <Value>allow</Value>

      </AttributeValuePair>

      <AttributeValuePair>

        <Attribute name="PUT" />

        <Value>allow</Value>

      </AttributeValuePair>

      <AttributeValuePair>

        <Attribute name="POST" />

        <Value>allow</Value>

      </AttributeValuePair>

    </Rule>

    <Subjects name="Subjects1" description="">

    <Subject name="subject1" type="Organization">

      <AttributeValuePair>

        <Attribute name="Values"/>

        <Value>dc=iplanet,dc=com</Value>

        <Value>o=nicp,dc=iplanet,dc=com</Value>

      </AttributeValuePair>

    </Subject>

    </Subjects>

    <Conditions name="Conditions1" description="">

    <Condition name="condition1" type="SampleCondition">

      <AttributeValuePair>

        <Attribute name="userNameLength"/><Value>5</Value>

      </AttributeValuePair>

    </Condition>

    </Conditions>

  </Policy>

</CreatePolicy>

</OrganizationRequests>

</Requests>

CreateServiceTemplate Element

The CreateServiceTemplate element creates a service template for the organization defined under the second-level Requests element. There are no sub-elements; the CreateServiceTemplate element itself must be empty. The required XML attribute is serviceName which takes a string value. Code Example 8-12 illustrates a User service template being registered to ou=Container1,dc=example,dc=com.

Code Example 8-12  contCreateServiceTemplateRequests.xml File

...

<Requests>

<ContainerRequests DN="ou=Container1,dc=example,dc=com">

<CreateServiceTemplate>

<Service_Name>iPlanetAMUserService</Service_Name>

</CreateServiceTemplate>

</ContainerRequests>

</Requests>

DeleteObject Elements

The DeleteSubOrganizations, DeletePeopleContainers, DeleteGroups, DeleteRoles, DeleteSubContainers, DeleteSubGroups, DeleteSubPeopleContainers, and DeleteUsers elements delete a sub-organization, people container, group, role, sub-container, sub-group, sub-people container and user, respectively. The object is deleted from the DN that is defined in the <Object>Requests element under which the particular Delete<Object> element is being defined. DeleteSubOrganizations, DeleteUsers, DeleteGroups, DeleteSubContainers, DeletePeopleContainers, DeleteSubGroups, DeleteSubPeopleContainers and DeleteRoles take a sub-element DN; only six of the listed elements have the XML attribute deleteRecursively. (DeleteUsers and DeleteRoles do not have this option; they have no qualifying XML attribute.) If deleteRecursively is set to false, accidental deletion of all sub-trees can be avoided; it’s default value is false. The DN sub-element takes a character value equal to the DN of the object to be deleted. Code Example 8-13 illustrates an example of some of these concepts. The DN is defined in the OrganizationRequests element as dc=example,dc=com.

Code Example 8-13  orgDeleteRequests.xml 

...

<Requests>

<OrganizationRequests DN="dc=example,dc=com">

<DeleteRoles>

<DN>cn=ManagerRole,dc=example,dc=com</DN>

<DN>cn=EmployeeRole,dc=example,dc=com</DN>

</DeleteRoles>

<DeleteGroups deleteRecursively="true">

<DN>cn=EmployeesGroup,dc=example,dc=com</DN>

<DN>cn=ContractorsGroup,dc=example,dc=com</DN>

</DeleteGroups>

<DeletePeopleContainers deleteRecursively="true">

<DN>ou=People1,dc=example,dc=com</DN>

</DeletePeopleContainers>

<DeleteSubOrganizations deleteRecursively="true">

<DN>o=sun.com,dc=example,dc=com</DN>

</DeleteSubOrganizations>

</OrganizationRequests>

</Requests>

DeletePolicy Element

The DeletePolicy element takes the sub-element PolicyName. The PolicyName element has no sub-elements; it must be empty. It has a required XML attribute name which takes a character value equal to the name of the policy. The DeletePolicy element itself takes a required XML attribute: deleteDN. It takes a value equal to the DN of the policy to be deleted.

DeleteServiceTemplate Element

The DeleteServiceTemplate element deletes the specified service template. There are no sub-elements; the DeleteServiceTemplate element itself must be empty. The required XML attributes are serviceName which takes a string value and schemaType which defines the attribute group (Global, Organization, Dynamic, User or Policy). Code Example 8-14 illustrates the deletion of the Membership Authentication Service from dc=example,dc=com.

Code Example 8-14  orgDeleteServiceTemplateRequests.xml 

<Requests>

<OrganizationRequests DN="dc=example,dc=com">

<DeleteServiceTemplate serviceName="iPlanetAMAuthMembershipService"

schemaType="organization"/>

</OrganizationRequests>

</Requests>

ModifyObject Elements

The ModifySubOrganization, ModifyPeopleContainer, ModifySubContainer, ModifyRole, and ModifySubGroups elements change the specified object. AttributeValuePair Elements can be defined for the listed elements. The required XML attribute is modifyDN which takes the DN of the object to be modified. Code Example 8-15 illustrates how the people container’s description can be modified.

Code Example 8-15  contModifyPeoplecontainerRequests.xml

<Requests>

<ContainerRequests DN="dc=sun,dc=com">

<ModifyPeopleContainer modifyDN="ou=Test,ou=Test1,ou=People1,dc=sun,dc=com">

<AttributeValuePair>

<Attribute name="Description"/>

<Value>Sun ONE Identity Server Modify</Value>

</AttributeValuePair>

</ModifyPeopleContainer>

</ContainerRequests>

</Requests>

ModifyServiceTemplate Element

The ModifyServiceTemplate element changes a specified service template. AttributeValuePair Element must be defined for ModifyServiceTemplate to change the values. The required XML attributes are serviceName which takes a string value, schemaType which defines the attribute group (Global, Organization, Dynamic, User or Policy) and roleTemplate. A search level attribute can also be defined. It takes a value of either SCOPE_ONE or SCOPE_SUB. SCOPE_ONE will retrieve just the groups at that node level; SCOPE_SUB gets groups at the node level and all those underneath it.

GetObject Elements

The GetSubOrganizations, GetUsers, GetSubGroups, GetGroups, GetSubContainers, GetRoles, GetPeopleContainers and GetSubPeopleContainers elements get the specified object. A DN may be defined as a sub-element (or not). If none is specified, ALL of the specified objects at all levels will be returned within the organization that is defined in the <Object>Requests element under which the particular Get<Object> element is being defined. The required XML attribute for all but GetGroups and GetRoles is DNsOnly and takes a true or false value. (This attribute is explained in more detail in DNs Only Attribute.) The required XML attribute of GetGroups and GetRoles is level which takes a value of either SCOPE_ONE or SCOPE_SUB. SCOPE_ONE will retrieve just the groups at that node level; SCOPE_SUB gets groups at the node level and all those underneath it. Code Example 8-16 illustrates how these elements can be modeled. The top-level DN is defined in the OrganizationRequests element as o=isp.

DNs Only Attribute

For all objects using the DNsOnly attribute, the Get elements work as stated below:

GetService Elements

The GetRegisteredServiceNames and GetNumberOfServices elements retrieve registered services and total number of registered services, respectively. The organization from which this information is retrieved is specified in the OrganizationRequests element. All three elements have no sub-elements or attributes; the elements themselves must be empty. Code Example 8-17 illustrates the GetNumberOfServices element.

Code Example 8-17  orgGetNumberOfServiceRequests.xml

<Requests>

<OrganizationRequests DN="dc=example,dc=com">

<GetNumberOfServices/>

</OrganizationRequests>

</Requests>

ActionServiceTemplate Element

The GetServiceTemplate and DeleteServiceTemplate elements get or delete a service template for the organization defined under the OrganizationRequests element, respectively. There are no sub-elements; the elements themselves must be empty. The required XML attributes are serviceName which takes a string value and schemaType.

ActionServiceTemplateAttributeValues Element

The AddServiceTemplateAttributeValues and RemoveServiceTemplateAttributeValues elements get or delete attribute values defined in a service template for the organization defined under the OrganizationRequests element, respectively. AttributeValuePair Element must be defined for each attribute to be added or removed. The required XML attributes are serviceName which takes a string value, roleTemplate and schemaType which defines the attribute group (Global, Organization, Dynamic, User or Policy). A search level attribute can also be defined. It takes a value of either SCOPE_ONE or SCOPE_SUB. SCOPE_ONE will retrieve just the groups at that node level; SCOPE_SUB gets groups at the node level and all those underneath it.

ActionServices Elements

The RegisterServices and UnregisterServices elements perform the requested action on the service defined in the OrganizationRequests element. All elements take a sub-element Service_Name but have no XML attribute. The Service_Name element takes a character value equal to the name of the service. One or more Service_Name sub-elements can be specified.

Service Action Caveats

Code Example 8-18 illustrates how the RegisterServices element is modeled.

Code Example 8-18  orgRegisterServiceRequests.xml 

<Requests>

<OrganizationRequests DN="dc=sun,dc=com">

<RegisterServices>

<Service_Name>sampleMailService</Service_Name>

</RegisterServices>

</OrganizationRequests>

</Requests>

SchemaRequests Element

The SchemaRequests element consists of all requests to be performed on the XML file that defines a particular service. It has two required XML attributes: serviceName takes a value equal to the name of the service where the schema lives, and SchemaType defines the attribute group (Global, Organization, Dynamic, User or Policy). The i18nFileName Attribute or a SubSchema (which specifies the complete hierarchy of the subschema separated by a “/”) can also be defined.

Note

See Service File Naming Conventions for information on how the name is defined.

This element can have one or more sub-elements. (Different SchemaRequests elements can be defined in one document to modify more than one service.) The sub-elements of SchemaRequests can include:

Code Example 8-19 illustrates the opening of the Requests element tag and its corresponding SchemaRequests sub-element. The file is adding the choice Deleted to the Default User Status drop-down menu in the User Service.

Code Example 8-19  schemaAddChoiceValuesRequests.xml

...

<Requests>

<SchemaRequests serviceName="iPlanetAMUserService"

SchemaType="dynamic"

i18nKey="">

<AddChoiceValues>

<AttributeValuePair>

<Attribute name="iplanet-am-user-login-status"/>

<Value>Active</Value>

<Value>Inactive</Value>

<Value>Deleted</Value>

</AttributeValuePair>

</AddChoiceValues>

</SchemaRequests>

</Requests>

RemoveDefaultValues Element

The RemoveDefaultValues element removes the default values from the service specified in the parent SchemaRequests element. It takes a sub-element of Attribute that specifies the service attribute which contains the values to be removed. The Attribute sub-element itself must be empty; it takes no sub-element. There is no required XML attribute. The syntax for this element is the same as that illustrated in Code Example 8-20.

Code Example 8-20  RemoveDefaultValues Element Code

...

<Requests>

<SchemaRequests serviceName="iPlanetAMUserService"

   SchemaType="dynamic">

<RemoveDefaultValues>

<Attribute name="preferredlanguage"/>

</RemoveDefaultValues>

</SchemaRequests>

</Requests>  

AddDefaultValues and ModifyDefaultValues Elements

The AddDefaultValues and ModifyDefaultValues elements add or change the default values from the specified schema, respectively. They take an AttributeValuePair Element which specifies the name of the attribute and the new default value; one or more attribute/value pairs can be defined. Code Example 8-21 illustrates how the AddDefaultValues element can be modeled.

Code Example 8-21  AddDefaultValues Element Code

...

<Requests>

<SchemaRequests serviceName="iPlanetAMUserService"

   SchemaType="dynamic">

<AddDefaultValues>

<AttributeValuePair>

<Attribute name="iplanet-am-user-auth-modules"/>

<Value>Cert</Value>

</AttributeValuePair>

</AddDefaultValues>

</SchemaRequests>

</Requests>  

GetServiceDefaultValues Element

The GetServiceDefaultValues element retrieves the default values from the schema specified in the parent SchemaRequests element. There are no sub-elements; the GetServiceDefaultValues element itself must be empty. There is also no required XML attribute.

Federation Management Elements

The following elements consist of requests that can be performed on Access Manager configured federations. They are:

For more information on these elements, see the DTD file itself located in the IdentityServer_base/SUNWam/dtd directory.

XML Service Files

Access Manager uses XML files to define service attributes as well as perform batch processing operations. This section contains information on the XML files included with Access Manager and how they are used.

Default XML Service Files

Access Manager installs services to manage the configurations of its components. The attributes for these services are managed using the Access Manager console; in addition, Access Manager provides code implementations to use them. These default XML service files are based on the sms.dtd and are located in etc/opt/SUNWam/config/xml. They include:

Modifying A Default XML Service File

Administrators can display and manage any attribute in the Access Manager console using XML service files. The new attribute(s) would need to be added to an existing XML service file. Alternately, they can be grouped into a new service by creating a new XML service file although the simplest way to add an attribute is just to extend an existing one. For example, an administrator wants to manage the nsaccountlock attribute which will give users the option of locking the account it defines. To manage it through Access Manager, nsaccountlock must be defined in a service. One option would be to add it to the amUser.xml service, iPlanetAMUserService. This is the service that, by default, includes many common attributes from the inetOrgPerson and inetUser object classes. Following is an example of how to add the nsaccountlock attribute to the amUser.xml service file.

  1. Add the code illustrated in Code Example 8-22 to the SubSchema name=User element in IdentityServer_base/SUNWam/config/xml/amUser.xml.

    2. Code Example 8-22  nsaccountlock Example Attribute  

    ...

    <AttributeSchema name="nsaccountlock"

    type="single_choice"

    syntax="string"

    any="filter"

    isChangeableByUser="yes"

    i18nKey="u13">

    <ChoiceValues>

    <Value>true</Value>

    <Value>false</Value>

    </ChoiceValues>

    <DefaultValues>

    <Value>false</Value>

    </DefaultValues>

    </AttributeSchema>

    ...

  2. Update the IdentityServer_base/SUNWam/locale/en_US/amUser.properties file with the new i18nKey tag u13 as illustrated in Code Example 8-23 (including the text to be used for display).

    3. Code Example 8-23  User Account Locked Example i18nKey

    ...

    u13=User Account Locked

    ...

  3. Remove the service ou=iPlanetAMUserService,ou=services,dc=sun,dc=com using the command line tool amadmin.

    4. For information on the amadmin command line syntax, see Sun Java System Access Manager Administration Guide.

  4. Reload the modified XML service file, amUser.xml, using the command line tool amadmin.

    5. For information on the amadmin command line syntax, see Sun Java System Access Manager Administration Guide.

    Note

    When modifying a default XML service file, be sure to also modify the Directory Server by extending the LDAP schema, if necessary. For more information, see Defining A Custom Service.

Batch Processing With XML Templates

The --data or -t option of amadmin is used to perform batch processing via the command line. Batch processing XML templates have been installed and can be used to help an administrator to:

The preferred way to perform most of these functions is to use the Access Manager console. The batch processing templates have been provided for ease of use with bulk updates although they can also be used for single configuration updates. This section provides an overview of the batch processing templates which can be modified to perform batch updates in the Directory Server.

Note

Only XML files can be used as input for the amadmin tool. If an administrator wants to populate the directory tree with user objects, or perform batch reads (gets) or deletes, the necessary XML input files, based on the amAdmin.dtd or sms.dtd, must be written.

XML Templates

All of the batch processing XML templates perform operations on the DIT; they create, delete, or get attribute information on user objects. These XML templates follow the structure defined by the amAdmin.dtd and are located in IdentityServer_base/SUNWam/samples/admin/cli/bulk-ops. The batch processing XML templates provided with Access Manager include:

Modifying A Batch Processing XML Template

Any of the templates discussed above can be modified to best suit the desired operation. Choose the file that performs the request, modify the elements and attributes according to the service and use the amadmin executable to upload the changes to Directory Server.

Note

Be aware that creations of roles, groups, and organizations is a time-intensive operation.

Customizing User Pages

The User profile page and what attributes it displays will vary, depending on what the service developer defines. By default, every attribute in the amUser.xml file that has an i18nKey attribute specified and the any attribute set to display (any=display) will display in the Access Manager console. Alternately, if an attribute is specified to be of type User in another XML service file, the Access Manager console will also display it if the service is assigned to the user. Thus, User display pages in the Access Manager console can be modified to add new attributes in either of two ways:

For information on modifying XML service files, see Modifying A Default XML Service File.

Note

Any service can describe an attribute that is for a user only. The amUser.xml file is just the default placeholder for user attributes that are not tied to a particular service.

Creating Users Using A Modified Directory Server Schema

There might be a need to modify the Directory Server LDAP schema in order to create users with new object classes. The procedure follows:

  1. Modify the Directory Server LDAP schema with the new object classes and attributes.

    2. For more information on how to do this, see the Sun Java System Directory Server documentation.

  2. Write a new XML service file which contains the definitions for the new object classes and attributes.

    3. When writing this file, the object classes should be defined under the Global element and the attributes should be defined under the User element. More information can be found in Chapter 8, "Service Management."

  3. Write a new authentication module credentials file and put it in the IdentityServer_base/SUNWam/lib directory.

    4. This file contains the attribute-value pairs for the internationalization keys used in the file created in Step 2. More information can be found in Configuring The Authentication Module of Chapter 5, "Authentication Service," in this manual.

    Note

    Alternately, the path to the module configuration properties file can be put in the classpath of the web container’s JVM.

  4. Load the XML service file using the amadmin command line interface.

    5. More information on this tool can be found in the Sun Java System Access Manager Administration Guide.

  5. Register the new service to the desired organization using the Access Manager console.

    6. For more details about registering a new service, refer to the Sun Java System Access Manager Administration Guide.

  6. Select the new service to create a user with the additional object classes.

    7. When creating new user there is an option to select the newly configured service.

Service Management SDK

The Access Manager provides a Java API for service management. These interfaces can be used by developers to register services and applications, and manage their configuration data. The interfaces and methods can be found in com.sun.identity.sm.

ServiceSchemaManager Class

The ServiceSchemaManager class in the com.sun.identity.sm package provides interfaces to manage a service’s schema. It must implement ServiceSchema which represents a single schema element in the service.

Retrieve Logging Location

Code Example 8-24 uses the ServiceSchemaManager class to retrieve the iplanet-am-logging-location attribute value from the Logging Service at the following DN: ou=iPlanetAMLoggingService,ou=services,o=isp.

Code Example 8-24  Retrieve Logging Location Sample

*********

SSOTokenManager manager = SSOTokenManager.getInstance();

SSOToken token = manager.createSSOToken(new

AuthPrincipal("uid=amadmin,ou=People,dc=org,dc=com"), "11111111");

ServiceSchemaManager ssm = new ServiceSchemaManager(token,

"iPlanetAMLoggingService", "1.0");

ServiceSchema ss = ssm.getGlobalSchema();

Map p = ss.getAttributeDefaults();

************

Retrieve User Or Dynamic Attributes

Code Example 8-25 uses the ServiceSchemaManager to define the ServiceSchema user attributes. AMUser.getAttributes(..) is then called to obtain the attribute/value pairs.

Code Example 8-25  Retrieve User Or Dynamic Attributes

ServiceSchemaManager ssm = new ServiceSchemaManager(serviceName, token);

ServiceSchema sm = ssm.getSchema(SchemaType.USER);

if (sm != null) {

Set userAttributes = ss.getAttributeSchemaNames();

// Since USER or DYNAMIC attributes are stored as ldap attributes you can call..

amUser.getAttributes(userAttributes);

}

Retrieve Attribute Values

Code Example 8-26 illustrates one way to retrieve attribute values from a service.

Code Example 8-26  Sample Code To Retrieve Attribute Values 

package com.iplanet.am.samples.sdk;

import java.io.*;

import java.net.*;

import java.util.*;

import com.iplanet.sso.*;

import com.iplanet.am.sdk.*;

import com.sun.identity.authentication.internal.*;

import com.sun.identity.sm.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class SampleUserOperations {

SSOToken token = null;

/**

* This user will be used for further sample operations on the

* same object

*/

private static AMUser contextUser = null;

private static String passWord = null;

private static String uid = null;

private static String lastName = null;

private static String firstName = null;

String userDN = null;

private static Map scuObjMap = new HashMap();

public static AMStoreConnection amsc = null;

public static SampleUserOperations suo;

//Here we will try to get the value of the organization type

//attribute "iplanet-am-auth-ldap-bind-dn" of the service

//"iPlanetAMAuthLDAPService" for the organization

//DN "dc=iplanet,dc=com".

public static void main(String args[]) {

try {

SSOTokenManager manager = SSOTokenManager.getInstance();

//If possible create the token using the tokneid or httprequest.

SSOToken token = manager.createSSOToken(new

AuthPrincipal("uid=amadmin,ou=People,dc=iplanet,dc=com"), "11111111");

suo = getSampleUserOperations(token);

amsc = new AMStoreConnection(token);

ServiceConfigManager scm = new ServiceConfigManager(token,

"iPlanetAMAuthLDAPService", "1.0");

String orgName = "dc=iplanet,dc=com";

ServiceConfig sc = scm.getOrganizationConfig(orgName, null);

Map mp = sc.getAttributes();

Iterator itr =

((HashSet)mp.get("iplanet-am-auth-ldap-bind-dn")).iterator();

System.out.println("bind dn for the org -" + orgName + "-is-" +

(String)itr.next());

System.exit(0);

} catch (Exception e) {

System.out.println("Exception Message: " + e.getMessage());

e.printStackTrace();

}

}

/* Basic Constructor */

public SampleUserOperations(SSOToken token) {

this.token = token;

scuObjMap.put(token, this);

}

/* Use the same object for multiple operations */

public static SampleUserOperations getSampleUserOperations(SSOToken token) {

SampleUserOperations scuObj = (SampleUserOperations)scuObjMap.get(token);

if (scuObj == null ) {

scuObj = new SampleUserOperations(token);

}

return scuObj;

}

/**

* This method will describe the SDK usage for creating a user.

* It uses AMStoreConnection to get the organization object

* It uses the Set Parameters to store the different attributes of

* the user. This method is used for command line.

* It throws an AMException if unable to create it and we throw

* message "unable to create" to the GUI by catching the same

*/

public String createUser(AMStoreConnection conn) {

try {

Map userAttributeMap = new HashMap();

uid = "user";

storeUserAttributes("uid", uid, userAttributeMap);

firstName = "user";

storeUserAttributes("givenname", firstName, userAttributeMap);

lastName = "one";

storeUserAttributes("sn", lastName, userAttributeMap);

passWord = "userone";

storeUserAttributes("userPassword", passWord, userAttributeMap);

Map userMap1 = new HashMap();

userMap1.put(uid, userAttributeMap);

/**

* Provide the DN according to the DIT

*/

String dn = "ou=People,o=iplanet.com,o=isp";

AMPeopleContainer ampc = conn.getPeopleContainer(dn);

ampc.createUsers(userMap1);

userDN = "uid=" + uid + "," + dn;

/*

* This is to keep the context of the user

*/

contextUser = conn.getUser(userDN);

return "Successfully added the user: " + uid;

} catch (Exception ex) {

ex.printStackTrace();

}

return "Unable to create";

}

/**

* This method will describe the SDK usage for creating a user.

* It uses AMStoreConnection to get the organization object

* It uses the Set Parameters to store the different attributes of

* the user.

* It throws an AMException if unable to create it and we throw

* message "unable to create" to the GUI by catching the same

*/

public String createUser(HttpServletRequest req, Set parameters, AMStoreConnection

conn) {

try {

Map userAttributeMap = new HashMap();

if (parameters.contains("uid")) {

uid = req.getParameter("uid");

storeUserAttributes("uid", uid, userAttributeMap);

}

if(parameters.contains("firstname")) {

firstName = req.getParameter("firstname");

storeUserAttributes("givenname", firstName, userAttributeMap);

}

if(parameters.contains("lastname")) {

lastName = req.getParameter("lastname");

storeUserAttributes("sn", lastName, userAttributeMap);

}

if(parameters.contains("password")) {

passWord = req.getParameter("userPassword");

storeUserAttributes("userPassword", passWord, userAttributeMap);

}

Map userMap1 = new HashMap();

userMap1.put(uid, userAttributeMap);

String orgDN = req.getParameter("orgName");

String dn = "ou=People" + "," + orgDN;

AMPeopleContainer ampc = conn.getPeopleContainer(dn);

ampc.createUsers(userMap1);

userDN = "uid=" + uid + "," + dn;

/*

* This is to keep the context of the user

*/

contextUser = conn.getUser(userDN);

return showCreateUserSuccess();

} catch (Exception ex) {

ex.printStackTrace();

}

return "Unable to create";

}

/**

* This method describes the SDK usage for modifying the user.

*/

public String modifyUser(HttpServletRequest req) {

HashMap modifyMap = new HashMap();

lastName = req.getParameter("lastname");

storeUserAttributes("sn", lastName, modifyMap);

firstName = req.getParameter("firstname");

storeUserAttributes("givenname", firstName, modifyMap);

passWord = req.getParameter("userpassword");

storeUserAttributes("userPassword", passWord, modifyMap);

try {

contextUser.setAttributes(modifyMap);

contextUser.store();

return showModifyUserSuccess();

} catch (Exception ex) {

System.out.println("Exception occured");

}

return "Unable to modify";

}

/**

* This method describes the SDK usage for deleting the user.

*/

public String deleteUser() {

try {

contextUser.delete(false);

return "Deleted successfully";

} catch (Exception ex) {

System.out.println("Exception occured");

}

return "Unable to delete";

}

/* This method is for the GUI purposes */

public String showCreateUser() {

StringBuffer sb = new StringBuffer();

sb.append("<HTML>");

sb.append("<HEAD>");

sb.append("</HEAD>");

sb.append("<BODY>");

sb.append("<FORM name=\"allattributes\" METHOD=POST

ACTION=\"/amserver/sdksample\">");

sb.append("<TABLE>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Login ID</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"uid\" VALUE=\"\"

SIZE=32 MAXLENGTH=64></TD><TD><B>Under Organization</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"orgName\" VALUE=\"\"

SIZE=32 MAXLENGTH=64></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>First Name</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"firstname\"

VALUE=\"\" SIZE=32 MAXLENGTH=64></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Last Name</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"lastname\" VALUE=\"\"

SIZE=32 MAXLENGTH=64></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Password</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"password\" NAME=\"userpassword\"

VALUE=\"\" SIZE=12></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Confirm Password</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"password\" NAME=\"passwordagain\"

VALUE=\"\" SIZE=12></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD><input type=SUBMIT NAME=\"usersubmit\">");

sb.append("</TD></TR>");

sb.append("</TABLE>");

sb.append("</FORM>");

sb.append("</BODY>");

sb.append("</HTML>");

return sb.toString();

}

private void storeUserAttributes(String attribute, String value, Map userMap) {

Set userSet = new HashSet();

userSet.add(value);

userMap.put(attribute, userSet);

}

/* This method is for the GUI purposes */

private String showCreateUserSuccess() {

StringBuffer sb = new StringBuffer();

sb.append("<HTML>");

sb.append("<HEAD>");

sb.append("</HEAD>");

sb.append("<BODY>");

sb.append("Created Successfully");

sb.append("<FORM name=\"usersuccessful\" METHOD=POST

ACTION=\"/amserver/sdksample\">");

sb.append("<TABLE>");

sb.append("<TR>");

sb.append("<TD><input type=SUBMIT NAME=\"modifyuser\" VALUE=\"Modify\">");

sb.append("</TD></TR>");

sb.append("</TABLE>");

sb.append("</FORM>");

sb.append("</BODY>");

sb.append("</HTML>");

return sb.toString();

}

/* This method is for the GUI purposes */

public String showModifyUser() {

StringBuffer sb = new StringBuffer();

sb.append("<HTML>");

sb.append("<HEAD>");

sb.append("</HEAD>");

sb.append("<BODY>");

sb.append("uid:" + uid);

sb.append("<FORM name=\"showmodify\" METHOD=POST

ACTION=\"/amserver/sdksample\">");

sb.append("<TABLE>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>First Name</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"firstname\"

VALUE=\"");

sb.append(firstName + "\" SIZE=32 MAXLENGTH=64></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Last Name</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"text\" NAME=\"lastname\"

VALUE=\"");

sb.append(lastName + "\" SIZE=32 MAXLENGTH=64></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD ALIGN=LEFT VALIGN=MIDDLE><B>Password</B></TD>");

sb.append("<TD VALIGN=MIDDLE><INPUT TYPE=\"password\" NAME=\"userpassword\"

VALUE=\"");

sb.append(passWord + "\" SIZE=12></TD>");

sb.append("</TR>");

sb.append("<TR>");

sb.append("<TD><input type=SUBMIT NAME=\"modifyusersubmit\">");

sb.append("</TD></TR>");

sb.append("</TABLE>");

sb.append("</FORM>");

sb.append("</BODY>");

sb.append("</HTML>");

return sb.toString();

}

/* This method is for the GUI purposes */

private String showModifyUserSuccess() {

StringBuffer sb = new StringBuffer();

sb.append("<HTML>");

sb.append("<HEAD>");

sb.append("</HEAD>");

sb.append("<BODY>");

sb.append("Modified Successfully");

sb.append("<FORM name=\"modifyusersuccessful\" METHOD=POST

ACTION=\"/amserver/sdksample\">");

sb.append("<TABLE>");

sb.append("<TR>");

sb.append("<TD><input type=SUBMIT NAME=\"deleteusersubmit\"

VALUE=\"Delete\">");

sb.append("</TD></TR>");

sb.append("</TABLE>");

sb.append("</FORM>");

sb.append("</BODY>");

sb.append("</HTML>");

return sb.toString();

}

/* This method is for the GUI purposes */

public String showDeleteUser() {

StringBuffer sb = new StringBuffer();

sb.append("<HTML>");

sb.append("<HEAD>");

sb.append("</HEAD>");

sb.append("<BODY>");

sb.append("<FORM name=\"showdelete\" METHOD=POST

ACTION=\"/amserver/sdksample\">");

sb.append("<TABLE>");

sb.append("<TR>");

sb.append("<TD><input type=SUBMIT NAME=\"deleteusersubmit\">");

sb.append("</TD></TR>");

sb.append("</TABLE>");

sb.append("</FORM>");

sb.append("</BODY>");

sb.append("</HTML>");

return sb.toString();

}

}



Previous      Contents      Index      Next     

Part No: 817-7649.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.