Symantec Access Management

<<TableOfContents>>

Overview of the new components in Siteminder R12

<<<Internal image(?): /image/image_gallery?uuid=9fc3b506-f3c8-4d3e-afb0-be22e0da1b1c&groupId=622992&t=1331868906229>>> <<<Internal image(?): /image/image_gallery?uuid=fc72ec76-036e-4560-9181-04e8768485fc&groupId=622992&t=1331868915230>>>

R12 Web Access Management UI

Differences in comparison to the Siteminder 6.x Administration UI:

• New Administration UI built on IAM Framework.
• New XPS API replaces Policy Management API and private admin API.
• XPS Extensions provide new Application policy support to Policy Server as well as supporting existing policy store objects.
• New XPS Store collocated with the existing Policy Store to store new objects.
• Requires no policy store migration.
• XPS store may be extended without schema changes.
• Application support is our first extension

Siteminder R12 has two graphical user interfaces that configure Siteminder policy objects:

• Administrative UI The Administrative UI is a web-based administration console that is installed independent of the Policy Server. Use the Administrative UI to view, modify, and delete all Policy Server objects except those related to Federation Security Services. All federation-related configuration tasks should be handled using the FSS Administrative UI.
• Federation Security Services Administrative UI (FSS Administrative UI) The FSS Administrative UI is an applet-based application that is installed with the Policy Server. The federation-specific UI objects consist of affiliates (consumers, service providers, resource partners) and SAML authentication schemes that you configure to support federated communication between two partners.

The intent of the FSS Administrative UI is to let you manage SiteMinder Federation Security Services. If you are familiar with previous versions of the SiteMinder Policy Server User Interface, you will notice that all SiteMinder objects appear in the FSS Administrative UI. The only objects that do not appear are objects related to Enterprise Policy Management (EPM) and reports. You can use the FSS Administrative UI to manage the SiteMinder objects. If you need information while using the FSS Administrative UI, consult the FSS Administrative UI online help system.

XPS

XPS Introduction

Acronym: XPS stands for eXtendable Policy Store. Short-Term Purpose: XPS was developed so that one would be able to add/modify object classes and attributes without having to modify the schema of the underlying repository (ODBC or LDAP). In the past, schema modifications often called for data migration on the customer's site, which is a highly undesirable course of action. Long-Term Purpose: XPS lays a basis for turning SiteMinder from a product into a platform, by making it possible to add new object classes in a "batch" called an XPS Product belonging to an XPS Vendor. When the API for this is published, it would be possible for customers to create their own products based on the XPS platform. For the time being, this functionality is used only for CA's in-house products, such as SOA and FrontRunner. Design: Conceptually, the XPS store's design is best illustrated by how XPS objects are stored in an ODBC object store.

Prior to XPS, the policy store ODBC schema defined a table for each object class (and a few additional tables for certain relationships). Objects were rows, and their attributes columns. Thus, in order to define a new class or a new attribute, one had to modify the schema.

In XPS, all objects are rows in a single table called xpsObject. Each of their attributes is a row in a single table called xpsProperty; each attribute refers to its container object by the object's Referential ID (RID) in the xpsObject table. Classes and attributes are objects themselves, of the object class CA.XPS::Class and CA.XPS::Attribute, respectively. Thus, in order to add/modify object classes and attributes in XPS, one only needs to create/update the corresponding objects in the store.

XPS Repositories: ODBC and LDAP storage is supported, the same as for SiteMinder Policy Store. In fact, the two stores must be co-located in the same database or LDAP instance.

XPS Objects

XPS objects are divided into the following five categories:

• Data Dictionary
• Policy Data
• Security Objects
• Configuration Parameters
• Meta Dictionary

Data Dictionary: XPS objects of this category are XPS vendors, products, object classes, attributes, and other related objects; for example, CA.SM::Domain or CA.SM::Policy classes and their attributes. Objects of this type can only be managed with the XPSDDInstall command line tool.

Policy Data: XPS objects of this category are instances of the object classes defined by the Data Dictionary; for example, Domain or Policy objects. This kind of objects corresponds to the objects stored in SiteMinder Policy Store. Objects of this type can be managed with WAM UI, XPS SDK, or the XPSExplorer command line tool.

Security Objects: XPS objects of this category define the XPS Security Model. Objects of this type can be managed with WAM UI, XPS SDK, or the XPSSecurity command line tool.

Configuration Parameters: XPS objects of this category define the configurable runtime environment of an XPS-based product (for example, SiteMinder Policy Server).

Meta Dictionary: XPS objects of this category are the hardcoded objects needed to define the other types of objects; for example, CA.XPS::Class and CA.XPS::Attribute classes and their attributes. Some hardcoded configuration parameters also belong to this category. Meta Dictionary objects cannot be created, deleted, or updated other than in another XPS release.

XPS XDD Install and Update

XPS Data Dictionary objects can only be created/modified with the XPSDDInstall command line tool. Once they are defined in the XDD file format, the XDD file(s) are passed to XPSDDInstall as a command line argument.

XDD Install

During XPS install, certain pre-defined XDD files are thus installed:

• SmObjects.xdd: Contains definitions for most of the CA.SM product's object classes, except for those related to Federation (FSS).
• FssObjects.xdd: Contains definitions for the Federation-related (FSS) object classes of the CA.SM product.
• EPMObjects.xdd: Contains definitions for the CA.EPM product's object classes.
• SecCat.xdd Contains definitions of pre-defined security categories. Note that SecCat.xdd must be installed last, since it may refer to object classes from any product. Example: [prompt]% XPSDDInstall SmObjects.xdd

XDD Update

XPS Data Dictionary objects can be updated by passing the new XDD file to the XPSDDInstall command line tool as an argument (the same command line example as above). Note that there are no delete instructions in XDD files. Thus, once a new version of the same Data Dictionary object is defined in an XDD file, then the entire object tree of this object is replaced. That is, if a previously existing child of the matching object is not found in the new XDD, it is deleted.

Potential Pitfall: Note that the CA.SM product is defined in the SmObjects.xdd file, but some of the CA.SM product's object classes are defined in a separate FssObjects.xdd file. Thus, if both XDD files are installed, and then only SmObjects.xdd is updated, then any objects defined in FssObjects.xdd will be gone. This means that FssObjects.xdd also must be updated immediately following an SmObjects.xdd update. (It may be worth considering concatenating the two.)

The update mechanism is as follows. If it is determined that a given Data Dictionary object is to be deleted, it is marked for deletion by settings the value of its Obsolete attribute to true. The reason for not deleting it immediately is that the deletion may not yet be possible if the object is being used by an existing object that is not yet marked for deletion (but may be marked later during the same update). The only exception is the ClassCategory objects, which are not used by any other object; thus, they do not have the Obsolete attribute and are deleted immediately.

This process is repeated in loops over all Data Dictionary objects. Once the number of obsolete objects stops increasing, looping stops and all marked objects are attempted to be deleted. If any cannot be deleted (because they are used by something), they remain and the Obsolete attribute is reset back to true. This is repeated in loops over all obsolete objects. Once no objects are deleted during an entire loop, the process stops and any remaining obsolete objects are retained and the Obsolete attribute value is flipped back to false.

XDD Syntax

An XPS Data Dictionary object is defined in XDD as follows:

• The first line contains the object's class in square brackets. Example: ~[Class~]
• The second line contains the object's parent, if any, as a name-value pair separated with "=". Example: PARENT=CA.SM
• The following lines contain the attribute values as the same kind of name-value pairs. Example: Name=Policy
• Not all attribute values need be specified. If an attribute has its default value defined, then it may be omitted.

The order of object definitions is important, since any objects referenced in the current object's attributes must already be defined. Thus, ~[Class~] definitions must precede ~[Attribute~] definitions, which must precede ~[Bit~] definitions, and so on. Since an ~[Attribute~] definition may refer to a Class (for example, as the value type of a link-valued attribute), it is best to define all Classes first, and only then to define any Attributes. Likewise, any extension Classes must be defined after the base Classes. Following these simple guidelines, one can always define any valid Data Dictionary configuration.

XPS tools

The policy export format and policy tools have been replaced by an XML-based export format, using XPSExport and XPSImport to migrate the data. The XML-based export format uses the following fundamental schemas:

• XPSDeployment.xsd Describes the top-level schema, which includes the other schemas. It defines the root element and sub-elements. An XML file conforming to this schema can contain an instance of Data Dictionary, Policy, and Security Data.

• XPSDataDictionary.xsd Describes meta-data information about object types and their properties.

• XPSPolicyData.xsd Describes the meta-data information about objects stored in the policy store, such as domains, policies, rules, applications, and the relationships between them.

• XPSSecurityData.xsd Describes meta-data used for representing policy store administrators and their access rights.

• XPSGeneric.xsd Contains definitions of the generic data types used in the other schema files.

This format supports not only exporting and importing policy data in its entirety, but also exporting and importing a subset of the policy data. A granular export presupposes knowledge of how the data will be imported. On export, you can specify the entire policy data, or a portion of the data using an object identifier and optionally one of these three export types:

• Add—specifies that only additions can be done during import.
• Replace—specifies an overwrite of existing policy data during import.
• Overlay—specifies that updates to policy data are done during import.

Note: The XPSExport and XPSImport tools encrypt sensitive data based on the FIPS mode the Policy Server is operating in. There are no additional parameters in these tools to set for data encryption.

XPSExport

The XPSExport tool supports the following tasks for migrating Policy Store data:

• Export all the data dictionary.
• Export all the security data.
• Export all the policy data.
• Export all the configuration data.
• Export a portion of the policy data. You can export a subset of policy data by specifying a root object's identifier in the command line or in a file (using the -xf parameter). Only objects that do not have a parent class can be exported. For example, to export a realm object, you specify the identifier (XID) of the realm's parent domain.

You can also create and edit a custom export file using the "shopping cart", or XCart, capability in XPSExplorer (xspexplorer -xf ). You can set the import mode (ADD, OVERLAY, REPLACE, or DEFAULT) on a per object basis in the XCart file. You can then pass the XCart file to XSPExport using the -xf parameter.

Consider the following:

• XPSExport does not export keys from the key store. You must use smkeyexport for this purpose.
• When moving SiteMinder policies from one environment to another, either as part of an upgrade or a policy migration, some objects that are environment–specific are included in the export file. Examples of these objects include:
• Trusted hosts
• HCO Policy Server settings
• Authentication scheme URLs
• Password services redirects
• Redirect responses Depending on the mode you select when using XPSExport, these objects may be added to the new environment or can overwrite existing settings. Be sure that you do not adversely affect environment settings when importing the objects.

XPSImport

The XPSImport tool supports the following tasks for migrating policy store data:

• Import the entire policy data.
• Import a portion of the policy data.
• Import configuration data. Note: XPSImport does not import keys into the key store. You must use smkeyimport for this purpose.

XPSCounter

To comply with the terms of your SiteMinder license, you can count the number of users in your SiteMinder environment. The following process describes how to configure your directories and count the SiteMinder users stored within them: Make the following changes to each user directory you want to count:

Note: For more information, see the SiteMinder Policy Server Configuration Guide. Require the use of Administrator Credentials by entering the user name and password of the directory administrator in the Administrative UI.

Define a Universal ID and other user attribute mappings using the Administrative UI. For Microsoft Active Directory user stores, map the inetOrgPerson attribute using the Administrative UI. Determine the number of users associated with SiteMinder policies.

XPSConfig

XPSConfig is an interactive command-line utility that allows administrators and members of operations to view product parameters and, if allowed, edit their settings. While you may have your own product-specific configuration tool using XPS programming interfaces, XPSConfig is available so that this is not a requirement. For each vendor and installed product, XPSConfig manages the parameters or named settings that are defined in the product's Data Dictionary. Each product can read, write, and validate its own parameter settings. To use XPSConfig, you must be an administrator with XPSConfig rights.

XPSEvaluate

XPSEvaluate is an interactive command-line utility that allows administrators and application developers to evaluate expressions and test performance. To use XPSEvaluate, you must be an administrator with XPSEvaluate rights.

XPSExplorer

XPSExplorer is an interactive command-line utility that allows an administrator or application developer to view the data in a policy store. XPSExplorer has two uses: To determine the identifiers of objects for a granular export or import by exploring a list of domains or realms To repair the object store in the event that the store is damaged and must be repaired manually. This action should be performed only under the guidance of CA support. To use XPSExplorer, you must be an administrator with XPSExplorer rights.

XPSExplorer includes the XCart feature. XCart allows you to collect the identifiers of the objects (XIDs) that you want to export and save them to a file for later use without manually copying and pasting each one. To use XPSExplorer, you must be an administrator with XPSExplorer rights.

XPSSecurity

XPSSecurity is an interactive command-line utility that allows administrators and members of operations to create and delete administrators and edit their rights. To use XPSSecurity, you must be an administrator with XPSSecurity rights.

XPSSweeper

XPSSweeper is a command-line utility that can also be run as a batch job. You can use XPSSweeper to synchronize XPS and SiteMinder policy stores. Usually, XPS synchronizes the different policy stores. However, when legacy tools are used, the policy stores may need to be resynchronized using XPSSweeper. In any case, XPSSweeper does not harm the policy stores and can be run as a precaution.

You can run XPSSweeper as a batch job by setting the following two XPS configuration parameters using XPSConfig:

• CA.XPS::$Autosweep
• CA.XPS::$Autosweep