test

Sun OpenSSO Enterprise 8.0 Developer's Guide

Chapter 14 Using the Client SDK

The SunTM OpenSSO Enterprise Client Software Development Kit (Client SDK) provides the Java libraries for integrating OpenSSO Enterprise functionality in remote standalone or web applications. This chapter contains the following sections:

About the Client SDK

The Client SDK includes the Java packages, classes, and configuration properties that you can use to enhance remote, standalone or web applications with the ability to access OpenSSO Enterprise. The Client SDK allows an application to use services such as authentication, SSO, authorization, auditing, logging, and the Security Assertion Markup Language (SAML). It also includes samples that you can run to help understand and develop code.

Caution – Caution –

The Client SDK is not for use by applications that perform policy management or identity management (which includes the creation and deletion of entries).

From a deployment point of view, the Client SDK offers the following:

For a description of these packages, see the Sun OpenSSO Enterprise 8.0 Java API Reference. A complete listing of the classes that comprise the Client SDK can be found in the ClientSDKClasses file available on the OpenSSO web site. Samples and source code are also included to help developers understand how the Client SDK can best be implemented.

Caution – Caution –

It is recommended that you do not use the com.iplanet.am.sdk, com.iplanet.am.util, com.sun.identity.policy, and com.sun.identity.sm packages directly.

OpenSSO Enterprise Client SDK Requirements

The requirements to use the Client SDK include:

Using the Client SDK

You can use the Client SDK to:

Using AMConfig.properties With the Client SDK

Although AMConfig.properties has been deprecated as the configuration data store for OpenSSO Enterprise, this file is still used to store configuration data for the Client SDK. An AMConfig.properties file with the information needed to point the Client SDK to the remote OpenSSO Enterprise server must be accessible from the machine on which it is hosted. The location of AMConfig.properties depends on how you initially installed the Client SDK.

If the Client SDK was installed by deploying the samples:

user.home/OpenSSO-Deploy-base-client-jdk15_AMConfig.properties

where user.home (JDK system property) is the home directory of the user running the web container, and OpenSSO-Deploy-base is determined by the web container. For example, if you deployed opensso-client-jdk15.war on Sun Java System Application Server 9.1 while running as super user (root), the AMConfig.properties file is:

OpenSSOClient/_opt_SUNWappserver_domains_domain1_applications_j2ee-modules_opensso-client-jdk15_AMConfig.properties

See Installing the Client SDK by Deploying the Sample WAR.

If the Client SDK was installed by compiling the samples:

opensso-client-zip-root/sdk/resources

See Installing the Client SDK By Compiling the Samples.

The properties in AMConfig.properties can be modified. Information on the properties in the file and how to modify them is in the following sections.

Properties in AMConfig.properties

The Client SDK uses the following properties in AMConfig.properties. You can add additional properties as required by a client application; for example, an application can register for the notification of changes to session attributes, user attributes, and policy decisions. The following sections contain information on the properties.

Note –

With the addition of new features, properties often change or might be added. For the most current properties, see AMClient.properties on the OpenSSO web site.

Debug Properties

Client SDK Related Properties

Logging Property

The value of com.iplanet.am.logstatus should be ACTIVE. INACTIVE disables logging.

Additional log properties are in Policy Logging and Caching Properties.

Java™ Platform, Enterprise Edition (Java EE) Agent Property

The value of com.iplanet.am.client.appssotoken.refreshtime is the amount of time (in minutes) that the appSSOToken will be refreshed. It defaults to 3.

Note –

A J2EE policy agent authenticates itself to OpenSSO Enterprise as an application using a special user. The OpenSSO sends back an appSSOToken after a successful authentication.

OpenSSO Enterprise Configuration Data User Credential Properties

See Setting Up a Client SDK Identity for additional information.

Cache Enable Properties

Two main components that rely heavily on caching for performance and improved user experience are the Service Management and Identity Repository classes. A combination of true and false values defined for the following three properties will enable and disable the respective cache.

Additional cache configuration properties include:

Additional cache properties are in Policy Logging and Caching Properties.

Cache Update Properties

When caching is enabled, OpenSSO Enterprise has three options that can be used to invalidate dirty cache entries. The first is to set up a URL with which the OpenSSO Enterprise server can send session change notifications to clients on remote web containers. This works for web and standalone applications that can listen for HTTP(s) traffic. The second method (which works ONLY if notification is disabled) is polling. In this case, the client periodically checks the OpenSSO Enterprise server for session changes. The third method is referred to as Time-to-Live (TTL) and enforces a limit on the period of time dirty data remains in the cache before it is discarded. See the following sections for more information.

Caution – Caution –

The notification method could cause a constant flood of notification changes that might overwhelm the client so be sure to choose the optimal method for your deployment.

Additional cache properties are in Policy Logging and Caching Properties.

Notification Properties

See Sending Notifications to the Client SDK Cache for more information on the Notification Service.

Polling Properties

Notification must be disabled.

TTL Properties

The following properties relate to the cache Time To Live (TTL). TTL is a limit on the period of time before data in the cache should be discarded. These TTL properties are not included in AMConfig.properties by default but can be added as needed. These are the Service Management TTL properties.

These are the Identity Repository TTL properties.

For backwards compatibility, these are the properties to configure the TTL feature for the com.iplanet.am.sdk classes.

Naming Property

com.iplanet.am.naming.url is a required property. The value of this property is the URI of the Naming Service from which the Client SDK would retrieve the URLs of OpenSSO Enterprise internal services; by default, http://opensso-host.domain_name:port/opensso/namingservice

Encryption Properties

OpenSSO Enterprise Server and Console Location Properties

These properties point to the OpenSSO Enterprise server and console. They are set during Client SDK configuration.

Cookie Property

com.iplanet.am.cookie.name contains the name of the OpenSSO Enterprise cookie; by default, iPlanetDirectoryPro.

Client Side Session Polling Properties

JSS Certificate Database Properties

Network Security Services for Java (JSS) is a Java interface to Network Security Services (NSS), a set of libraries designed to support cross-platform development of security-enabled client and server applications. The following properties are used to initialize the JSS SocketFactory when the web container in which the Client SDK is deployed is configured for SSL.

These properties identify the value for SSL ApprovalCallback. If the checkSubjectAltName or resolveIPAddress feature is enabled, you must create cert7.db and key3.db with a prefix equal to the value defined in com.iplanet.am.admin.cli.certdb.prefix and located in the directory defined in com.iplanet.am.admin.cli.certdb.dir.

Policy Logging and Caching Properties

Federation Properties

These federation properties are not included in AMConfig.properties by default but can be added as needed.

com.sun.identity.liberty.ws.soap.supportedActor

Defines the SOAP supported actors. Each actor must be separated by a pipe (|).

Note –

A SOAP message can travel from a sender to a receiver by passing different endpoints along the way but not all parts of the SOAP message may be intended for the destination; some may be intended for one or more endpoints along the message path. The SOAP actor attribute is used to address the Header element to a specific endpoint URL.

com.sun.identity.liberty.interaction.wspRedirectHandler

Defines the URL for WSPRedirectHandlerServlet to handle Liberty the WSF web service provider-resource owner. Interactions are based on user agent redirects. The servlet should be running in the same JVM where the Liberty service provider is running.

com.sun.identity.liberty.interaction.wscSpecifiedInteractionChoice

Indicates whether the web service client should participate in an interaction. Valid values are interactIfNeeded, doNotInteract, and doNotInteractForData. Default value is interactIfNeeded which is used if an invalid value is specified.

com.sun.identity.liberty.interaction.wscWillInlcudeUserInteractionHeader

Indicates whether the web service client should include userInteractionHeader. Valid values are yes and no (case ignored). Default value is yes. Default value is used if no value is specified.

com.sun.identity.liberty.interaction.wscWillRedirect

Indicates whether the web service client will redirect user for an interaction. Valid values are yes and no. Default value is yes. Default value is used if no value is specified.

com.sun.identity.liberty.interaction.wscSpecifiedMaxInteractionTime

Indicates the web service client preference for acceptable duration (in seconds) for an interaction. If the value is not specified or if a non-integer value is specified, the default value is 60.

com.sun.identity.liberty.interaction.wscWillEnforceHttpsCheck

Indicates whether the web service client enforces that redirected to URL is HTTPS. Valid values are yes and no (case ignored). The Liberty specification requires the value to be yes. Default value is yes. Default value is used if no value is specified.

com.sun.identity.liberty.interaction.wspWillRedirect

Indicates whether the web service provider redirects the user for an interaction. Valid values are yes and no (case ignored). Default value is yes. Default value is if no value is specified.

com.sun.identity.liberty.interaction.wspWillRedirectForData

Indicates whether the web service provider redirects the user for an interaction for data. Valid values are yes and no. Default value is yes. If no value is specified, the value is yes.

com.sun.identity.liberty.interaction.wspRedirectTime

Web service provider expected duration (in seconds) for an interaction. Default value if the value is not specified or is a non-integer value is 30.

com.sun.identity.liberty.interaction.wspWillEnforceHttpsCheck

Indicates whether the web service client enforces that returnToURL is HTTP. Valid values are yes and no (case ignored). Liberty specification requires the value to be yes. Default value is yes. If no value is specified, then the value used is yes.

com.sun.identity.liberty.interaction.wspWillEnforceReturnToHostEqualsRequestHost

Indicates whether the web services client enforces that returnToHost and requestHost are the same. Valid values are yes and no. Liberty specification requires the value to be yes.

com.sun.identity.liberty.interaction.htmlStyleSheetLocation

Indicates the path to the style sheet used to render the interaction page in HTML.

com.sun.identity.liberty.interaction.wmlStyleSheetLocation

Indicates the path to the style sheet used to render the interaction page in WML.

com.sun.identity.liberty.ws.interaction.enable

Default value is false.

com.sun.identity.wss.provider.config.plugin= com.sun.identity.wss.provider.plugins.AgentProvider

Used by the web services provider to determine the plug-in that will be used to store the configuration.

For example: com.sun.identity.wss.provider.config.plugin= com.sun.identity.wss.provider.plugins.AgentProvider

com.sun.identity.loginurl

Used by the web services clients in Client SDK mode. For example:

com.sun.identity.loginurl=https://host:port/opensso-uri/UI/Login

com.sun.identity.liberty.authnsvc.url

Indicates the Liberty authentication service URL.

com.sun.identity.liberty.wsf.version

Used to determine which version of the Liberty identity web services framework is to be used when the framework can not determine from the inbound message or from the resource offering. This property is used when OpenSSO Enterprise is acting as the web service client. The default version is 1.1. The possible values are 1.0 or 1.1.

com.sun.identity.liberty.ws.soap.certalias

Value is set during installation. Client certificate alias that will be used in SSL connection for Liberty SOAP Binding.

com.sun.identity.liberty.ws.soap.messageIDCacheCleanupInterval

Default value is 60000. Specifies the number of milliseconds to elapse before cache cleanup events begin. Each message is stored in a cache with its ownmessageID to avoid duplicate messages. When a message's current time less the received time exceeds thestaleTimeLimit value, the message is removed from the cache.

com.sun.identity.liberty.ws.soap.staleTimeLimit

Default value is 300000. Determines if a message is stale and thus no longer trustworthy. If the message timestamp is earlier than the current timestamp by the specified number of milliseconds, the message the considered to be stale.

com.sun.identity.liberty.ws.wsc.certalias

Value is set during installation. Specifies default certificate alias for issuing web service security token for this web service client.

com.sun.identity.liberty.ws.trustedca.certaliases

Value is set during installation. Specifies certificate aliases for trusted CA. SAML or SAML BEARER token of incoming request. Message must be signed by a trusted CA in this list. The syntax is:

cert alias 1[:issuer 1]|cert alias 2[:issuer 2]|.....

For example: myalias1:myissuer1|myalias2|myalias3:myissuer3. The value issuer is used when the token doesn't have a KeyInfo inside the signature. The issuer of the token must be in this list, and the corresponding certificate alias will be used to verify the signature. If KeyInfo exists, the keystore must contain a certificate alias that matches the KeyInfo and the certificate alias must be in this list.

Setting Properties in AMConfig.properties

There are three ways to set properties in AMConfig.properties. The following sections contain more information.

Setting Properties Using a Text Editor

You can set properties in AMConfig.properties by editing the file with a text editor. Each property is defined as:

property-name=property-value

Setting Properties Using the Java API

You can set properties programmatically using the com.iplanet.am.util.SystemProperties class. For example:

Example 14–1 Setting Client SDK Properties Programmatically


import com.iplanet.am.util.SystemProperties;
import java.util.Properties;
public static void main(String[] args) {
        // To initialize a set of properties
        Properties props = new Properties();
        props.setProperty(”com.iplanet.am.naming.url’, 
        ”http://sample.com/opensso/namingservice’);
        props.setProperty(”com.sun.identity.agents.app.username’, ”URLAccessAgent’);
        props.setProperty(”com.iplanet.am.service.password’, ”11111111’);
        SystemProperties.initializeProperties(props) ;

        // To initialize a single property
        SystemProperties.initializeProperties(“com.iplanet.am.naming.url’, 
        ”http://sample.com/opensso/namingservice’);
    // Application specific code ...
}

Setting Properties at Run Time

To set a value to a particular property at run time, declare the JVM option using the following format:

-Dproperty-name=property-value

Installing the Client SDK and Running the Samples

There are two ways to install the Client SDK. These options are documented in the following sections:

Installing the Client SDK by Deploying the Sample WAR

opensso-client.zip is in the samples directory of the downloaded and inflated opensso.zip. Unzipping opensso-client.zip reveals the war and sdk directories. The war directory contains two versions of the Client SDK WAR depending on the version of Java installed on your machine.

The following sections contain the procedures for deploying the Client SDK WAR and running the web-based and command line samples.

ProcedureTo Install the Client SDK by Deploying the Sample WAR

Before You Begin

  1. Copy the compressed opensso-client.zip to a staging directory on the host machine where you plan to deploy the Client SDK.

  2. Unzip opensso-client.zip.

  3. Set the JAVA_HOME environment variable to JDK 1.5 or 1.4, depending on the version of Java installed on your machine.

  4. Deploy the appropriate Client SDK WAR (opensso-client-jdk14.war or opensso-client-jdk15.war) depending on the version of Java installed on your machine.

  5. After successful deployment, launch the Client SDK configuration screen.

    Configure the Client SDK screen

  6. Provide the appropriate values pertaining to the instance of OpenSSO Enterprise with which the Client SDK will be communicating.

    • Server Protocol Protocol (http or https) used by the web container on which OpenSSO Enterprise is deployed.

    • Server Host Fully qualified domain name (FQDN) of the host machine on which OpenSSO Enterprise is deployed.

    • Server Port Port used by OpenSSO Enterprise server.

    • Server Deployment URI URI defined during OpenSSO Enterprise deployment. The default is /opensso. Be sure to include the leading slash (/).

    • Debug directory: Location of the debug directory; for example, /opensso/debug

    • Application user name:: The policy agent user that communicates with OpenSSO Enterprise; by default, agentAuth.

    • Application user password: Password of the policy agent user that communicates with OpenSSO Enterprise.

  7. Click Configure.

    A message signifying successful configuration is displayed.

    A message signifying successful configuration is displayed.

    AMConfig.properties for the Client SDK is also created. AMConfig.properties has been deprecated for OpenSSO Enterprise. The server configuration data is now stored in an embedded data store. The Client SDK, however, still uses AMConfig.properties to store its configuration data as it is remote to the installed OpenSSO Enterprise server. For information about the location of the AMConfig.properties file and setting properties in the file, see Using AMConfig.properties With the Client SDK.

ProcedureTo Run the Client SDK Web-based Samples

Before You Begin

This procedure assumes you have completed To Install the Client SDK by Deploying the Sample WAR and the successful configuration screen is still displayed.

  1. Click the word here on the successful configuration screen displayed at the end of To Install the Client SDK by Deploying the Sample WAR.

    The web-based samples introduction page is displayed.

    Client SDK samples page

  2. Click Access Management Samples.

    The Client SDK - Samples page is displayed.

    The Samples page is displayed.

  3. Click Service Configuration Sample Servlet.

    The Service Configuration Sample page is displayed.

    The Service Configuration Sample page is displayed.

  4. Enter the password for the amadmin user.

  5. Choose either Schema or Config from the drop-down list.

    Schema refers to the data structure of the service. Default values may be defined dependent of the service. Config is the actual data. The output is defined as key/value pairs.

  6. Click Submit.

    ServiceConfigServlet.java retrieves the attributes of the Authentication Service (or other input service) and the SSOToken of the questioning user.

    Tip –

    If an error message is displayed, confirm that the com.sun.identity.agents.app.username has a value of agentAuth and com.iplanet.am.service.password has a value of changeit in the Client SDK AMConfig.properties. If you need to modify this file, restart the underlying web container.

  7. Click Back to Access Management Samples.

  8. Click User Profile (Attributes) Sample Servlet.

    The User Profile Sample page is displayed.

  9. Enter the password for the default amadmin or another defined user name and password and click Submit.

    The UserProfileServlet.java retrieves and displays the profile that corresponds to the user ID entered in the Username text box.

  10. Click Back to Access Management Samples.

  11. Click Policy Evaluator Client Sample Servlet.

    The Policy Evaluator Client Sample page is displayed.

  12. Open a new browser window, login to OpenSSO Enterprise, and using the console, create a policy for the resource http://www.sun.com:80 with a GET allow and POST deny rule for all authenticated users on Fridays.

  13. Back on the Policy Evaluator Client Sample page, enter the amadmin password and the resource http://www.sun.com:80.

  14. Click Submit.

    PolicyClientServlet.java is the call on the client side that initiates the retrieval of a policy decision (from the Policy Service) that would be passed to a web agent for enforcement.

  15. Click Back to Access Management Samples.

  16. Log in to the OpenSSO Enterprise as amadmin if not already.

    You must be logged in and have an SSOToken for the Single Sign On Token Verification Servlet.

  17. Back on the Access Management Samples page, click Single Sign On Token Verification Servlet.

    The user profile associated with the SSOToken received after successful authentication is displayed. The code included with this sample is SSOTokenSampleServlet.java and SampleTokenListener.java. These files serve as a basis for using the SSO API, demonstrating how you can create an SSOToken, call various methods from the token, set up an event listener and get notified on event changes.

Next Steps

Two other samples using the Client SDK are included on the web-based samples introduction page: the Liberty ID-WSF 1.x Web Service Consumer Sample and the Security Token Service (WS-Trust) Client Sample. See the instructions for these samples when you click the sample name.

ProcedureTo Run the Client SDK Command Line Samples

This procedure documents compiling the command line samples as well as running them. It uses the scripts for the Solaris and Linux operating systems. opensso-client-zip-root refers to the directory in which you decompressed the appropriate Client SDK WAR.

Caution – Caution –

Be sure to run all the scripts discussed one level up from the directory in which they are found.

Before You Begin

This procedure assumes you have completed To Install the Client SDK by Deploying the Sample WAR and the successful configuration screen is still displayed.

  1. On the command line of the machine on which the Client SDK is installed, change to opensso-client-zip-root/sdk/scripts and run chmod to make the scripts executable.


    # cd opensso-client-zip-root/sdk/scripts
# chmod 755 *.sh

  2. Execute compile-samples.sh to compile the scripts.


    # cd ../
# scripts/compile-samples.sh

  3. Run the setup script to initialize the command line samples.


    # cd ../
# scripts/setup.sh
    Note –

    Use setup.bat on Windows systems.

    The script uses Main.java and creates AMConfig.properties with a pointer to the opensso-client-zip-root/sdk/resources directory.

  4. Run the individual Client SDK samples by executing the rest of the scripts in the /scripts directory.

    Login.sh/Login.bat

    Uses Login.java to log in and log out a user.

    CommandLineSSO.sh/CommandLineSSO.bat

    Uses CommandLineSSO.java to retrieve a user profile.

    CommandLineIdrepo.sh/CommandLineIdrepo.bat

    Uses its myriad source files to perform operations on the identity data store. For example, create an identity, delete an identity, and search or select an identity.

    CommandLineLogging.sh/CommandLineLogging.bat

    Uses its myriad source files (including LogSample.java) to demonstrate the login process and write a log record of a successful authentication. You will need to authenticate two identities: the subject of the LogRecord and the logger (amadmin).

    SSOTokenSample.sh/SSOTokenSample.bat

    to verify an SSOToken. Uses SSOTokenSample.java to demonstrate this and other functions of the session API.

    Note –

    Before running this sample, you will need an SSO Token ID. You can get this by running the Service Configuration Sample in To Run the Client SDK Web-based Samples and copying the ID that is displayed.

    run-policy-evaluation-sample.sh/run-policy-evaluation-sample.bat

    Returns a policy decision based on console created user and configured policy. Uses the code sourced in the policy directory on opensso.dev.jave.net.

    run-xacml-client-sample.sh/run-xacml-client-sample.bat

    Uses XACMLClientSample.java to construct a XACML request, to make an authorization query, receive the decision, and print out the response.

    Note –

    At run time, a sample might require additional property files to be setup in the /resources directory. Check the comments included in each individual script for more information.

Installing the Client SDK By Compiling the Samples

You can also install the Client SDK by compiling the samples yourself. The procedure is documented in opensso-client.zip.

opensso-client.zip is in the samples directory of the downloaded and inflated opensso.zip. Unzipping opensso-client.zip reveals the war and sdk directories. The sdk directory contains source code that needs to be compiled before use and includes the following sub directories:

Note –

These samples can be run in a standalone JVM outside of a web container.

ProcedureTo Install the Client SDK by Compiling the Samples

Before You Begin

  1. Copy the compressed opensso-client.zip to a staging directory on the host machine where you plan to deploy the Client SDK.

  2. Unzip opensso-client.zip.

  3. Change to the sdk directory.

  4. Follow the README to configure the Client SDK and, compile and run the samples.

Sending Notifications to the Client SDK Cache

Notifications enable the synchronization of the Client SDK cache and the OpenSSO Enterprise server. You can use the Notification Service to send session notifications to web containers that are running the OpenSSO Enterprise Client SDK, enabling real-time updates on the client side. No client application changes are required to support session notifications. The notifications can be received only if the Client SDK is installed on a web container. See Properties in AMConfig.properties for information on the notification properties.

ProcedureTo Enable Client SDK Cache Notifications

Before You Begin

Copy the encryption value of am.encryption.pwd from the OpenSSO Enterprise server to the remote Client SDK. The value of am.encryption.pwd is used for encrypting and decrypting passwords.

To access the am.encryption.pwd, in OpenSSO Enterprise administration console, click Configuration > Servers and Sites > serverName > Security.

  1. Install OpenSSO Enterprise on Host 1.

  2. Install Sun Java System Web Server on Host 2.

  3. Install the ClientSDK on the same machine as the Web Server.

  4. Log in to OpenSSO Enterprise as amadmin.

    http://OpenSSO-HostName:8080/opensso

  5. Execute the servlet by entering http:// ClientSDK_host:8080/servlet/SSOTokenSampleServlet into the browser location field and validating the SSOToken.

    SSOTokenSampleServlet is used for validating a session token and adding a listener. Executing the servlet will print out the following message:

    SSOToken host name: 192.18.149.33 SSOToken Principal name: uid=amAdmin,ou=People,dc=red,dc=iplanet,dc=com Authentication type used: LDAP IPAddress of the host: 192.18.149.33 The token id is AQIC5wM2LY4SfcyURnObg7vEgdkb+32T43+RZN30Req/BGE= Property: Company is - Sun Microsystems Property: Country is - USA SSO Token Validation test Succeeded

  6. Set the property com.iplanet.am.notification.url= in the machine where the Client SDK is installed:


    com.iplanet.am.notification.url=http://clientSDK_host.domain:port
/servlet
    com.iplanet.services.comm.client.PLLNotificationServlet

    The notification URL is where the OpenSSO server can send change notifications to the clients. This works for web application and standalone applications that can listen on port for HTTP(s) traffic.

  7. Restart the Web Server.

  8. Login into OpenSSO Enterprise as amadmin.

    http://OpenSSO-HostName:8080/opensso

  9. Execute the servlet by entering http:// ClientSDK_host:8080/servlet/SSOTokenSampleServlet into the browser location field and validating the SSOToken again.

    When the machine on which the Client SDK is running receives the notification, it will call the respective listener when the session state is changed. The notifications can be received only if the Client SDK is installed on a web container.

Setting Up a Client SDK Identity

Some OpenSSO Enterprise components (such as SAML, user management, and policy) require an identity to be authenticated before the client application can read configuration data. The client can provide either a username and password that can be authenticated, or an implementation of the com.sun.identity.security.AppSSOTokenProvider interface. Either option will return a session token which the client can then use to access OpenSSO Enterprise configuration data.

To Set Username and Password Properties

The following properties in AMConfig.properties can be used to set the username and password. The authenticated username should have permission to read the OpenSSO Enterprise configuration data.

To Set an SSO Token Provider

Add the com.sun.identity.security.AdminToken property to AMConfig.properties with a value equal to the name of the implementation of the com.sun.identity.security.AppSSOTokenProvider interface.

Using the Virtual Federation Proxy Client Interfaces

OpenSSO Enterprise contains both Java and .Net interfaces to enable applications using Virtual Federation Proxy (also referred to as Secure Attribute Exchange). They are provided as follows:

For more information, see the README in zip-root/opensso/libraries/native/dll and Using SAML v2 for Virtual Federation Proxy.