Tuesday Jan 19, 2010

Using OpenSSO with Microsoft Geneva Server

I just posted MICROSOFT® “GENEVA” SERVER AND SUN OPENSSO: ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS. This paper (written by another) focuses on Sun OpenSSO Enterprise and Microsoft Geneva Server — specifically, on their common support for the Security Assertion Markup Language (SAML) federation standard as a basis for interoperability. The paper:
  • Presents an overview of solutions and capabilities, both individual and interoperable solutions.
  • Describes the business benefits of interoperability between the two.
  • Shares detailed use cases demonstrating proven interoperability in real-world federation scenarios.
But before you leave, it's not Geneva, it's Vienna by Utravox.

Thursday Jan 14, 2010

Evaluating OpenSSO Entitlements Using REST

This is part three of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part one is Authenticating for the OpenSSO Entitlements Service REST Interfaces, part two is Listening for the OpenSSO Entitlements Service Using REST, and part four is Managing OpenSSO Entitlements Using REST.

With the upcoming release of OpenSSO Express 9, REST interfaces in the form of URLs have been developed to evaluate policies and return decisions from the Entitlements Service. All of the policy evaluation interfaces support HTTP GET and POST actions, and some of them return JavaScript Object Notation (JSON) objects.

The policy evaluation URLs begin with the base which is appended with a specific string based on the action desired. One or more parameters are then added based on the information required by the action. The format of the OpenSSO REST policy evaluation URL is:

http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/OpenSSO-REST-string?parameter1=value1&parameter2=value2&parameterN=valueN

The available policy evaluation interfaces (which replace OpenSSO-REST-string in the URL) are decision, entitlement, decisions, and entitlements. If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

NOTE: Prior to making a call using one of these RESTful interfaces, the subject must authenticate to OpenSSO and get a session token identifier. The SHA1 hashed value of this token.id then needs to be base64 encoded and used as input for these REST URLs. See Authenticating for the OpenSSO Entitlements Service REST Interfaces for more information.

The following sections contain more information.

Evaluating a Decision for One Resource

The decision interface returns a plain text string of deny or allow in regards to a request for access. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • action defines the action to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • resource defines the resource to be evaluated.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
    1. requestDnsName - The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user's SSOToken.
    2. requestIp - The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
    3. requestTime - For example, env=requestTime%3D1248994000000.
    4. requestTimeZone - The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/decision?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&action=GET
&application=iPlanetAMWebAgentService
&resource=http://www.example.com:80/index.html
&env=requestIp%3D125.12.122.4

This example REST call might return a plain text allow if the subject has permission to access http://www.example.com:80/index.html with GET method and client IP address 125.12.122.4.

Evaluating a Decision and Returning Additional Information for One Resource

The entitlement interface returns a list of JSONEntitlement objects in regards to a request for access. Although similar to the decision interface, it allows more information to be returned. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • resource defines the resource to be evaluated.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
    1. requestDnsName - The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user's SSOToken.
    2. requestIp - The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
    3. requestTime - For example, env=requestTime%3D1248994000000.
    4. requestTimeZone - The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/entitlement?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resource=http://www.example.com:80/index.html
&env=requestIp%3D125.12.122.4

In the following result for this example, statusCode":200 signifies that the REST call has succeeded. Additionally, the policy evaluation confirms that the subject has permission to access http://www.anotherexample.com:80/index.html using the GET method from the client IP address 125.12.122.4.

{
     "statusCode":200,
     "statusMessage":"OK"
     "body":{
          "actionsValues":{"GET":true},
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.anotherexample.com:80/index.html"
      }
 }

Evaluating a Decision for Multiple Resources

The decisions interface returns a list in the form of a JSONEntitlements object in regards to a request for access to a set of resources. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • resources defines the set of resources to be evaluated. More than one resources parameter may be added to the URL.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
    1. requestDnsName - The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user's SSOToken.
    2. requestIp - The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
    3. requestTime - For example, env=requestTime%3D1248994000000.
    4. requestTimeZone - The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/decisions?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resources=http://www.example1.com:80/index.html
&resources=http://www.example2.com:80/index.html
&resources=http://www.example3.com:80/index.html
&env=requestIp%3D125.12.122.4

In the following result for this example, statusCode":200 signifies that the REST call has succeeded. Additionally, the policy evaluation confirms that the subject has permission to access http://www.example2.com:80/index.html using the GET method from the client IP address 125.12.122.4. The subject does not have permission, though, to access http://www.example2.com:80/index.html using the GET method from the client IP address 125.12.122.4 because it does not fall within the specified range defined as a condition of the policy: 128.122.18.1 to 128.122.18.254. No decision has been made for the third resource, http://www.example3.com:80/index.html.

 {
       "statusCode":200,
       "statusMessage":"OK"
       "body":{
         "results":[
         {
            "actionsValues":{"GET":true},
            "attributes":{},
            "advices":{},
            "resourceName":"http://www.example1.com:80/index.html"
         }
         {
            "actionsValues":{"GET":false},
            "attributes":{},
            "advices":{
                "com.sun.identity.entitlement.IPCondition":[
                     "requestIp=128.122.18.1-128.122.18.254"
                ]
            },
            "resourceName":"http://www.example2.com:80/index.html"
         }
         {
            "actionsValues":{},
            "attributes":{},
            "advices":{},
            "resourceName":"http://www.example3.com:80/index.html"
         }
         ]
       },


    }

Evaluating a Decision for A Root and Sub Tree Resources

The entitlements interface takes a given root resource and provides the decisions for all of its sub resources. It returns a list in the form of a JSONEntitlements object in regards to the request for access. For example, given the root resource of http://www.example.com, results for all sub resources (including http://www.example.com/hr/\*, http://www.example.com/eng/\* and http://www.example.com/sales/\*) will be returned. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • resource defines the root of the set of resources to be evaluated.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
    1. requestDnsName - The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user's SSOToken.
    2. requestIp - The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
    3. requestTime - For example, env=requestTime%3D1248994000000.
    4. requestTimeZone - The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.
For this example, assume that http://www.examplefour.com:80 has two sub resources: /index.html and /hr/index.html.

http://www.example.com:8080/opensso/ws/1/entitlement/entitlement?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resource=http://www.examplefour.com:80
&env=requestIp%3D125.12.122.4
In the following result statusCode":200 signifies that the REST call has succeeded. Additionally, the policy evaluation confirms that the subject has permission to access http://www.examplefour.com:80/index.html using the GET method from the client IP address 125.12.122.4. The subject does not have permission, though, to access http://www.examplefour.com:80/hr/index.html using the GET method from the client IP address 125.12.122.4 because it does not fall within the specified range defined as a condition of the policy: 128.122.18.1 to 128.122.18.254.
{
  "statusCode":200,
  "statusMessage":"OK"
  "body":{
    "results":[
    {
       "actionsValues":{},
       "attributes":{},
       "advices":{},
       "resourceName":"http://www.anotherexample.com:80"
    }
    {
       "actionsValues":{"GET":true},
       "attributes":{},
       "advices":{},
       "resourceName":"http://www.anotherexample.com:80/index.html"
    }
    {
       "actionsValues":{"GET":false},
       "attributes":{},
       "advices":{
           "com.sun.identity.entitlement.IPCondition":[
                "requestIp=128.122.18.1-128.122.18.254"
           ]
       },
       "resourceName":"http://www.anotherexample.com:80/hr/index.html"
    }
    ]
  },


}

Be aware though this will not work if you are wicked - as illustrated by Cage the Elephant in their song Ain't No Rest for the Wicked.

Wednesday Jan 13, 2010

Listening for the OpenSSO Entitlements Service Using REST

This is part two of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part one is Authenticating for the OpenSSO Entitlements Service REST Interfaces, part three is Evaluating OpenSSO Entitlements Using REST, and part four is Managing OpenSSO Entitlements Using REST.

There are RESTful management interfaces that can be used to get, add and remove listeners which send notifications to the Entitlements Service when privileges are added, removed, or modified. The listener management interfaces support HTTP GET, DELETE, and POST actions, and returns a JavaScript Object Notation (JSON) object.

The listener management URLs begin with the base which is appended with the encoded URL of the listener. One or more parameters are then added based on the information required by the action. The format of the OpenSSO REST listener management URL is:

http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/listener/encoded-URL?parameter1=value1&parameter2=value2&parameterN=valueN

To get or remove a listener configuration, use the base of the URL (http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/listener/) and replace encoded-URL with the appropriate listener URL. To add a new listener, append the base URL with the appropriate parameters. If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

NOTE: Prior to making a call using one of these RESTful interfaces, the subject must authenticate to OpenSSO and get a session token identifier. The SHA1 hashed value of this token.id then needs to be base64 encoded and used as input for these REST URLs. See Authenticating for the OpenSSO Entitlements Service REST Interfaces for more information.

Adding a Listener

This interface uses HTTP POST to add the listener configuration for the specified resource. The URL may be populated with the following information.
  • url defines the URL of the listener.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • application defines the generic resource type. See The Entitlements Service In OpenSSO Express 8 for more information.
  • resources defines one or more resources for which the listener is configured.
For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener?
url=http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&resources=http://www.example1.com/\*

This REST call returns a JSON object affirming the successful addition of the listener.
{
   "statusCode":201,
   "statusMessage":"Created",
   "body":"Created"
}

Retrieving a Listener

This interface uses HTTP GET to return a JSON representation of the specified listener configuration. The URL may be populated with the following information.
  • encoded-URL is appended to the end of the REST URL (before the parameters) and is the encoded URL of the listener.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener/
http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON representation of the listener. The example below means that there is a listener for all privileges regarding _http://www.example1.com_.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
        "mapAppToRes":{
             "iPlanetAMWebAgentService":[
                  "http://www.example1.com/\*"
             ]
        },
        "url":"http://www.listenerresttest.com/notification"
   }
}

Removing a Listener

This interface uses HTTP DELETE to remove the specified listener. The URL may be populated with the following information.
  • encoded-URL is appended to the end of the REST URL (before the parameters) and is the URL of the listener.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener/
http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON object affirming the successful removal of the listener.

{ 
  "statusCode":200, 
   "statusMessage":"OK", 
   "body":{ 
      "result":"OK" 
   } 
}

And while we're listening, here's Pseudo Echo with their 1981 Aussie hit, Listening.

Tuesday Jan 12, 2010

Authenticating for the OpenSSO Entitlements Service REST Interfaces

This is part one of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part two is Listening for the OpenSSO Entitlements Service Using REST, part three is Evaluating OpenSSO Entitlements Using REST, and part four is Managing OpenSSO Entitlements Using REST.

The OpenSSO Entitlements Service provides fine grained access control. With the upcoming release of OpenSSO Express 9, RESTful interfaces (in the form of URLs) have been developed for the Entitlements Service. (Information on other OpenSSO RESTful interfaces can be found .)

Before using the Entitlements Service REST interfaces, the user making the calls needs to be authenticated and receive a session token identifier. Following authentication, this identifier must be hashed and encoded for input as a parameter value of the Entitlements Service REST URLs. The following sections have more information.

Authenticating to OpenSSO Before Using REST

Before making a REST call using one of the Entitlements Service URLs, the subject must authenticate to OpenSSO using the authenticate REST identity interface. This identity call, if successful, will get a session token identifier for the subject that will then be used as input for the Entitlements Service REST URLs. An example of the authenticate REST URL is:

http://www.example.com:8080/opensso/identity/authenticate?username=user1&password=changeme

NOTE: For this use, the authenticate URL should use HTTP POST because (the default) HTTP GET logs the user information which might be a security issue in some deployments.

This authenticate call would return a session token.id; for example:

token.id=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

This session token.id needs to be set as the iPlanetDirectoryPro cookie.

iPlanetDirectoryPro=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

Additionally, a SHA1-hashed and base64 encoded string needs to be generated from the value of the token.id. This encoded string, representing the user, will be passed as a parameter with every REST call.

Encoding the token.id

This procedure will generate a SHA1-hashed and base64 encoded string from the session token.id previously returned.
  1. Compile the Encoder.java code found on opensso.dev.java.net.

    javac Encoder.java
  2. Run the compiled Encoder to hash and encode the session token.id.

    java Encoder AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=

The Encoder returns a string such as vd6RXuEnYJl93VWftk9plOzAqfQ=. This string is a SHA1 hash that is also base64 encoded. It must be passed as a parameter with every REST call to indicate the subject; for example:

subject=vd6RXuEnYJl93VWftk9plOzAqfQ=

The actual information on the Entitlements Service REST interfaces will be forthcoming. (And this entry will make more sense. ;> ) It includes policy evaluation, privilege management and listener management REST interfaces. In the meantime, take the Rest of the Day Off from Neil Finn's 2001 album - Bowie-esque from his Heroes period.


Friday Jan 08, 2010

Born To Change a Configured OpenSSO Host Name

After opensso.war is deployed in a web container, the installed OpenSSO instance is uniquely identified by a URL defined with a protocol (http/https), a host name, a port and a deployment URI; for example, http://ipg-test2.sun.com:8080/opensso. This URL is defined in the OpenSSO bootstrap file as well as in various places in the service configuration data store.

When the web container on which OpenSSO is deployed is restarted, OpenSSO uses the bootstrap URL to locate its system properties in the service configuration data store and start itself. Additionally, almost all federation and web services endpoints contain this URL. Thus, to change the host name on which the instance of OpenSSO has been installed, use the first procedure in this entry. The second procedure documents how to restore the previous host name.

To Change the OpenSSO Host Name
To Restore the Previous Configuration

To Change the OpenSSO Host Name

For this example procedure, assume the current OpenSSO URL is http://current.example.com:58080/opensso, and the new OpenSSO URL will be http://new.example1.com:8080/opensso1.
  1. Login to the OpenSSO console as administrator; by default, amadmin.
  2. Click the Access Control tab.
  3. Click / Top Level Realm.
  4. Add the new host name as a value for the Realm/DNS Aliases attribute. For example, new.example1.com.
  5. Export the service configuration data to a file named export.xml.
    See Backing Up and Restoring Configuration Data for information.
  6. Copy export.xml to new.xml.
  7. Open new.xml and make the following changes.
    1. Search for <SubConfiguration name=”http://current.example.com:58080/opensso” id=”server”> and:
      • Change <Value>com.iplanet.am.services.deploymentDescriptor=/opensso</Value> to <Value>com.iplanet.am.services.deploymentDescriptor=/opensso1</Value>
      • Change <Value>com.iplanet.am.server.port=58080</Value> to <Value>com.iplanet.am.server.port=8080</Value>
      • Change <Value>com.iplanet.am.server.host=current.example.com</Value> to <Value>com.iplanet.am.server.host=new.example1.com</Value>
    2. Search for <Service name=”iPlanetAMAuthConfiguration” version=”1.0”><Schema i18nFileName=”amAuthConfig” i18nKey=”iplanet-am-auth-config-service-description” propertiesViewBeanURL=”opensso/auth/ACServiceInstanceList”> and change opensso to opensso1.
    3. Search for <SubSchema inheritance=”multiple” maintainPriority=”no” name=”NamedConfiguration” supportsApplicableOrganization=”no” validate=”yes”><AttributeSchema cosQualifier=”default” i18nKey=”a101” isSearchable=”no” name=”iplanet-am-auth-configuration” propertiesViewBeanURL=”opensso/auth/ACModuleList”> and change opensso to opensso1.
    4. Search for <AttributeSchema cosQualifier=”default” i18nKey=”a133” isSearchable=”no” name=”iplanet-am-auth-login-success-url” syntax=”string” type=”list”><DefaultValues><Value>/opensso/console</Value> and change opensso/ to opensso1/.
    5. Search for <AttributeValuePair><Attribute name=”sunOrganizationAliases”/><Value>opensso</Value> and change opensso to opensso1.
    6. Search for <AttributeSchema cosQualifier=”default” i18nKey=”a103” isSearchable=”no” name=”iplanet-am-platform-cookie-domains” syntax=”string” type=”list”><DefaultValues><Value>.example.com</Value> and change the cookie domain from .example.com to .example1.com.
    7. Substitute the following strings:
      • http://new.example1.com:8080/opensso1 for http://current.example.com:58080/opensso
      • new.example1.com:8080 for current.example.com:58080
  8. Save new.xml.
  9. Backup the OpenSSO configuration data.
    This backup can be used to restore a previous configuration. If the OpenSSO configuration data store is the default embedded OpenDS, backup the contents of OpenSSO-ConfigDir. OpenSSO-ConfigDir represents the name of the directory specified during initial configuration of OpenSSO as the configuration directory. By default, an opensso directory would be created in the home directory of the user configuring the instance. Thus, if root is configuring the instance, OpenSSO-ConfigDir is /opensso. If any other directory server is used, work with the administrator to back up the OpenSSO configuration data before proceeding.
  10. Import new.xml back into OpenSSO.
    See Backing Up and Restoring Configuration Data for information.
  11. Stop the web container.
  12. Replace http%3A%2F%2Fcurrent.example.com%3A58080%2Fopensso with http%3A%2F%2Fnew.example1.com%3A8080%2Fopensso1 in the OpenSSO-ConfigDir/bootstrap file.
    During OpenSSO deployment, a setup servlet creates a file named bootstrap in the OpenSSO configuration directory. This file contains the information that points to a location from which OpenSSO can retrieve configuration data to bootstrap itself. For more information on this file, see The OpenSSO Bootstrap File Deconstructed.
  13. Change the deploy context on the OpenSSO web container to opensso1.
    Check the your web container's documentation for instructions.
  14. Move OpenSSO-ConfigDir/opensso to OpenSSO-ConfigDir/opensso1.
    Be sure to backup this directory first.
  15. Change to the user-home/.openssocfg directory.
    A file named with the prefix AMConfig is in this directory; for example, AMConfig_usr_local_tomcat_webapps_opensso or AMConfig_opt_jboss-4.2.2.GA_server_fam2_._deploy_opensso.war_. user-home is the home directory of the user who configured the instance of OpenSSO.
  16. Change opensso in the AMConfig\* file to opensso1.
  17. Start the web container.
  18. Log in to OpenSSO using the new URL (and host name) as amadmin.
  19. Click the Access Control tab.
  20. Click / Top Level Realm.
  21. Remove current.example.com, the old host name, from the Realm/DNS Aliases attribute.

To Restore the Previous Configuration

This procedure is based on the examples and information used in the previous procedure.

  1. Edit OpenSSO-ConfigDir/bootstrap by changing the new encoded URL back to the old encoded URL.
  2. Import export.xml back into OpenSSO.
  3. Change the deploy context on the OpenSSO web container back to opensso.
  4. Move OpenSSO-ConfigDir/opensso1 to OpenSSO-ConfigDir/opensso.
  5. Change opensso1 in the AMConfig\* file (located in the user-home/.openssocfg directory) back to opensso.
  6. Restart the web container.

Now enjoy Patrick Hernandez's one hit Born to Be Alive.

Monday Jan 04, 2010

Happy New Year Authenticating to OpenSSO Monitoring Service

A monitoring framework based on the Java Dynamic Management Kit (JDMK) was introduced in OpenSSO Express Build 8. Access to OpenSSO's monitoring data may be via the HTTP, SNMP (Simple Network Management Protocol), or RMI (Remote Method Invocation) interfaces.

In OpenSSO Express Build 9 (and currently available in the nightly build), access to the Monitoring Service's HTTP interface has been modified to require authentication to access OpenSSO monitoring data through the HTTP interface. (An HTML Protocol Adaptor comes with the JDMK and is used to authenticate. See The HTML Protocol Adaptor for more information.)

The opensso_mon_auth file contains the name and password of the user (or users) with permission to log in and see the OpenSSO monitoring data. It is located in the /ConfigurationDirectory/install-URI/ directory created during the OpenSSO installation; by default, /opensso/opensso/opensso_mon_auth. The file initially contains the user demo with an encrypted value equal to the password changeit. This user can be replaced or additional users added to the file. Type any user identifier followed by a space and the encrypted value of the user's password. The user name is case-sensitive and the password must be encrypted using the ampassword command line tool. It is located in the ssoAdminTools.zip which is in the tools directory of the expanded opensso.zip. For more information see Installing the OpenSSO Enterprise Utilities and Scripts.

NOTE: The user in this file is not tied in any respect to the OpenSSO user data store. Authentication to the monitoring data using the HTML Protocol Adaptor is a separate authentication process from that of OpenSSO.

Now just a little wish from ABBA (and me, by proxy) for all to enjoy the new year and decade. Happy New Year from the Super Trouper LP - an acronym from many new years ago.

Tuesday Dec 22, 2009

Importing the Root CA Certificate for Secure OpenSSO Rainbow Connections

When configuring OpenSSO for a scenario that involves a secure connection (SSL or LDAPS) and multiple JVMs, you need to import the root CA certificate into the JVM trust store (by default JAVA_HOME/jre/lib/security/cacerts) and restart the OpenSSO web container before performing any configurations.

For example, to configure a second instance of OpenSSO in a defined Site (when the first instance of OpenSSO is SSL-enabled), the root Certificate Authority (CA) certificate for the first OpenSSO server certificate must be imported into the JVM key store of the web container in which the second instance of OpenSSO is deployed. (Restart the web container of the second instance after the import.)

An example of a command to import a root CA certificate to this key store is:

keytool -import -v -alias alias -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file CAcert.crt

Use the following command to verify that the root CA certificate was imported correctly.

keytool -list -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit

Now enjoy a secure Rainbow Connection with Deborah Harry and Kermit the Frog.

Monday Dec 21, 2009

A URL List for the Relay State You're In

When an identity provider and a service provider are communicating using SAMLv2 (a redirect or an assertion exchange, for example), the RelayState parameter is used to store the URL to which the user will be redirected after the action (single sign-on, single log out or termination, for example) is complete. (If a RelayState value is not specified, the value of the defaultRelayState property in the extended metadata configuration of the entity provider is used. See Constructing SAML Messages in the Sun OpenSSO 8.0 Developer's Guide for more information.)

To avoid the RelayState parameter's being used to redirect the user to an invalid site, the Relay State URL List has been added as an Advanced property in the Standard Administration Console to the hosted identity provider, the hosted service provider and the Fedlet metadata. The value of this property is essentially a white list of URLs. If the property contains no URLs, no further check is done and the user is redirected to the URL value of the RelayState parameter as per usual. If URLs are specified, both the hosted identity provider and hosted service provider (or Fedlet, if applicable) will check the value of the RelayState parameter in the communication against the URLs and, if there is a match, redirection to the value of the RelayState parameter is allowed. If there is no match, the user is shown a browser error indicating Invalid Relay State URL specified.

To add to the Relay State URL List, log in to the OpenSSO Standard Administration Console as administrator.

  1. Click the Federation tab.
  2. Click the name of the appropriate hosted entity provider from the Entity Providers table.
  3. Click the Advanced tab.
  4. Click Relay State URL List (or scroll to the page's bottom).
  5. Add one or more URLs based on the following supported patterns.
    • \*
    • http://host:port/\*
    • http://\*:\*/\* - (if no port number is specified, defaults to 80 as the protocol is http)
    • https://\*:\*/\* - (if no port number is specified, defaults to 443 as the protocol is https)
    • http://\*:\*/\*?\* - (if query string is present)
    • http://host:port/-\*-/test - (one level wild card support)
  6. Click Save.

Now enjoy this video from (very early) Bananarama - State I'm In. They look like they're in a Dexy's Midnight Runners state.

Or if you prefer the Squeaky Mix - half the time, double the BPM and quadruple the laughs.

Tuesday Dec 15, 2009

If You Have To Change The amadmin Password Out of the Box

Since the password for amadmin is encoded and hashed it is hard to change the password once OpenSSO is installed as we don't offer the option or utility to encode and hash the password. Unofficially, there is a way to change the lost or forgotten password of amadmin. It's not supported and this is the only thing written on it so be sure not to lose or forget your password. But just in case...

BEFORE YOU BEGIN: The password for amadmin and Directory Manager of the configuration data store is the same by default. So before you can make any changes to the configuration data store, you will need to reset the password for the OpenDS Directory Manager. Use the ldappasswordmodify command as illustrated:

$ ldappasswordmodify -h localhost -p 1389 --authzID "dn:cn=Directory Manager" --currentPassword mypassword --newPassword mynewpassword

It should return:

The LDAP password modify operation was successful

Now follow these instructions to reconfigure the configuration data store using the new Directory Manager password when it is requested.

  1. Connect to the Configuration Data Store using an LDAPBROWSER client.
  2. Navigate to --> ou=Services --> ou=iPlanetAMPlatformService --> ou=1.0 --> ou=GlobalConfig --> ou=Default --> ou=com-sun-identity-servers --> ou=http://:/opensso.
  3. Select ou=http://:/opensso. Its different attributes and associated values are displayed on the right. Note the value of attribute sunKeyValue displays serverconfig=am.encryption.pwd=password1234. If there is another instance of OpenSSO that has the same value for am.encryption.pwd as this one, the passwords and encryptions are the same. Continue with step 5 to change the password. Otherwise, continue with step 4.
  4. Install an instance of OpenSSO in a test environment using the same value of am.encryption.pwd as the one above.
  5. Connect to the Configuration Data Store on the temporary instance using an LDAPBROWSER client.
  6. Navigate to to --> ou=Services --> ou= sunIdentityRepositoryService --> ou=1.0 --> ou=GlobalConfig --> ou=Default --> ou=users --> ou=amAdmin.
  7. Select ou=amAdmin. Its different attributes and associated values are displayed on the right. The value of sunKeyValue is displayed as userPassword=AQICGCVs587Ld67ZkiWlqauzaXQAqvx8g6YECMW/jzK62WNdhnBceHNEwg==.
  8. Navigate to the Configuration Data Store on which you want to change the password and replace the old value with this new one.
  9. Restart the web container.
  10. Login using the password of the temporary environment that was copied.
And now enjoy Wanda Jackson performing The Box That It Came In. She's pretty angry but it has nothing to do with the out-of-the-box password.

Wednesday Dec 09, 2009

Destination Unknown: OpenSSO Common Tasks Links on Tomcat

Some folks internally who use Tomcat as a web container have found the Google Apps and SalesForce links on the Common Tasks page of the OpenSSO Administration Console missing after deploying the opensso.war. From what I understand - I'm a Glassfish user myself - it occurs after installing the latest patch on Tomcat.

If you notice this, remove the opensso directory from $CATALINA_HOME/work/Catalina/local-host-name/ and restart the container. The links should appear.

Here's a live clip of Missing Persons performing Destination Unknown at the US Festival 1983.

Tuesday Dec 08, 2009

Could It Be the OpenSSO OAuth Token Service?

An early access version of the OpenSSO OAuth Token Service is now available in the nightly builds. OAuth provides a method for exchanging user credentials for an access token. This token, authorized by a user, grants access to private resources from the user's account on one service provider site to a second, consumer site - without having to divulge identity information (including user name and password). The OpenSSO OAuth Token Service supports parts of the OAuth Core 1.0 Specifications including consumer registration, Request Token requests, Request Token authorizations, and Access Tokens. The following sections contain information on the OpenSSO OAuth Token Service as it stands today.

OpenSSO OAuth Token Service Overview

An OAuth consumer site needs to register with the OpenSSO OAuth Token Service used by the service provider site before it can request OAuth tokens. Once registration has been successful, the registered consumer site can get an unauthorized OAuth Request Token on behalf of a user. The user agent (browser) will be redirected to the service provider site where the user authenticates and is then asked to authorize or revoke the Request Token. (The user is asked to enter a user name and password.) After a successful authorization, the user agent is redirected back to the consumer site with an authorized Request Token. The consumer site then sends a request to the service provider site for an Access Token that enables the consumer site to access the resources on the service provider site. More detailed information is in the following sections:

Registering An OAuth Consumer Site

An OAuth service provider requires each consumer site to register, and get a consumer key, before being able to make OAuth requests. When the Service Consumers Metadata Management page is displayed by accessing http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/oauth/index.jsp, enter a Service Consumer Name and an optional Service Consumer URI. Click the Register button to complete the registration. Upon successful registration, the OAuth Token Service returns a response similar to the following.
Service Consumer registered.
consumer_key=http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/consumer/7faf3762e2b048e2b4998f3e65c376b4
consumer_secret=5fe61f1ad7f445f9b63793916c561dd7
The consumer key and consumer secret should be kept in a secure location as they will be needed to identify this particular consumer.

You can also use the Service Consumers Metadata Management page to delete a registered consumer site. Enter the consumer key (returned when the consumer site was originally registered) of the consumer site to be deleted in the Service Consumer Key field and click Delete to remove it.

Requesting User Authorization as an OAuth Request Token

An unauthorized OAuth Request Token is used by a consumer site to get approval from a user to access resources from the user's service provider account. A registered consumer site can request an unauthorized Request Token from http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/get_request_token. The request should use HTTP POST, must be signed, and should contain the following parameters:
  • oauth_consumer_key is the consumer key returned when the consumer site was originally registered with the OAuth service provider.
  • oauth_signature_method is the signature method used by the consumer site to sign the request. All Request Token requests must be signed by the consumer site and verified by the service provider. Supported signature methods are HMAC-SHA1 and PLAINTEXT.
  • oauth_signature is the generated signature. The consumer site declares a signature method, generates a signature, and stores it as the value of this parameter. The service provider then verifies the signature as specified by each method.
  • oauth_timestamp is the timestamp. Unless otherwise specified, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. It must be a positive integer and equal or greater than the timestamp used in previous requests.
  • oauth_nonce is a random string, generated for each request by the consumer site, that is unique for all requests with a particular timestamp.
  • oauth_version is an optional parameter that defines the OAuth specification version being used. If defined, the value must be 1.0.
The response to the Request Token request should contain the following parameters:
  • oauth_token is the Request Token.
  • oauth_token_secret is the Token Secret used for verification.
The user will need to authorize this request before an Access Token is granted.

Authorizing An OAuth Request Token

A user authorizes an OAuth Request Token through redirection to the OpenSSO OAuth Token Service Authorization Console at http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/oauth/userconsole.jsp. If not yet authenticated by OpenSSO, the user will be redirected to the OpenSSO login page. Once the user successfully authenticates, the OpenSSO OAuth Token Service Authorization Console is displayed with the choice to authorize or revoke the Request Token request.

The request should use HTTP GET (in many cases, the user is redirected to this URL by the consumer site) and should contain the following parameters:
  • oauth_token is the Request Token to be authorized.
  • oauth_callback is the URL that the OpenSSO OAuth Token Service will use to redirect the user back to the consumer site after user authorization is complete.
Following a successful OAuth authorization, the Oauth Token Service constructs an HTTP GET request URL to redirect the user to the oauth_callback URL with the authorized Request Token as the value of oauth_token.

Requesting an OAuth Access Token

An authorized Request Token is used to request an OAuth Access Token which will allow the consumer site access to the user's service provider account. A registered consumer site can request an Access Token from http(s)://OSSO-host:OSSO-port/OSSO-deploy-uri/resources/1/oauth/get_access_token. The request should use HTTP POST, must be signed, and should contain the following parameters:
  • oauth_consumer_key is the consumer key returned when the consumer site was originally registered with the OAuth service provider.
  • oauth_token is the authorized Request Token.
  • oauth_signature_method is the signature method used by the consumer site to sign the request. All Request Token requests must be signed by the consumer site and verified by the service provider. Supported signature methods are HMAC-SHA1 and PLAINTEXT.
  • oauth_signature is the generated signature. The consumer site declares a signature method, generates a signature, and stores it as the value of this parameter. The service provider then verifies the signature as specified by each method.
  • oauth_timestamp is the timestamp. Unless otherwise specified, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. It must be a positive integer and equal or greater than the timestamp used in previous requests.
  • oauth_nonce is a random string, generated for each request by the consumer site, that is unique for all requests with a particular timestamp.
  • oauth_version is an optional parameter that defines the OAuth specification version being used. If defined, the value must be 1.0.
The response to the Access Token request should contain the following parameters:
  • oauth_token is the Access Token.
  • oauth_token_secret is the Token Secret used for verification.
Using the OAuth Token Service Sample

OpenSSO has an OAuth Token Service sample using the Stock Service and Stock Client sample code. The files are available in the OpenSSO source code or in a ZIP archive I put together and uploaded to the OpenSSO site. Refer to the included README file for details. It's pretty easy to run through.

And now enjoy this video of the Queen of Disco, Donna Summer, performing Could It Be Magic LIVE. Remember when singers actually used their vocal chords in live performances?

Wednesday Nov 25, 2009

Tail the OpenSSO SSOToken Then Go! Get Turkey

Here is an unofficial way to see the properties in the SSOToken. The SSOToken is the building block of an OpenSSO session. It is used to collect and retrieve session data such as the authenticated principal name, authentication method, session idle time and maximum session time. In order to see exactly what is in the SSOToken change the debug level of the OpenSSO server to Message.
  1. Log into the OpenSSO Console as administrator.
  2. Click the Configuration tab.
  3. Click the Servers and Sites tab.
  4. Click the appropriate server link in the Servers table.
  5. Click the debugging link.
  6. Select Message from the drop down options.
  7. Click Save.
Now, on the command line, tail the Session Service debug log. The debug files are located in the opensso configuration directory. For example, when OpenSSO is deployed using Glassfish, you can find Session in /opensso/opensso/debug.

tail Session

Now login as any configured user and then logout that user. The Session debug log will display the details of the SSOToken being destroyed as in the following display.

amSession:11/10/2009 12:38:26:619 PM PST: Thread[httpSSLWorkerThread-8080-4,10,Grizzly]
SESSION NOTIFICATION : <Session sid="AQIC5wM2LY4SfcyyvOv3Tm/JuNoXMKfnEd85nsdDk+wUiEc=@AAJTSQACMDE=#"
 stype="user" cid="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com" cdomain="dc=red,dc=iplanet,dc=com"
 maxtime="120" maxidle="30" maxcaching="3" timeidle="10" timeleft="7190" state="destroyed">
<Property name="CharSet" value="UTF-8"></Property>
<Property name="UserId" value="upgradeuser"></Property>
<Property name="FullLoginURL" value="/opensso/UI/Login?module=LDAP"></Property>
<Property name="successURL" value="/opensso/console"></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4Sfcyl+XOus5I2hMB3fSXnY89LPuRsnyRinQ8=@AAJTSQACMDE=#"></Property>
<Property name="UserToken" value="upgradeuser"></Property>
<Property name="loginURL" value="/opensso/UI/Login"></Property>
<Property name="IndexType" value="module_instance"></Property>
<Property name="Principals" value="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"></Property>
<Property name="moduleAuthTime" value="LDAP+2009-11-10T20:38:16Z|anon1+2009-11-10T20:37:44Z"></Property>
<Property name="amlbcookie" value="01"></Property>
<Property name="sun.am.UniversalIdentifier" value="id=upgradeuser,ou=user,dc=red,dc=iplanet,dc=com"></Property>
<Property name="Organization" value="dc=red,dc=iplanet,dc=com"></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="HostName" value="xxx.yyy.aaa.bbb"></Property>
<Property name="com-iplanet-am-console-location-dn" value="dc=red,dc=iplanet,dc=com"></Property>
<Property name="AuthType" value="LDAP|anon1"></Property>
<Property name="UserProfile" value="Required"></Property>
<Property name="Host" value="xxx.yyy.aaa.bbb"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="AMCtxId" value="6747059ed30ea08a01"></Property>
<Property name="authInstant" value="2009-11-10T20:38:16Z"></Property>
<Property name="Principal" value="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"></Property>
</Session>

And now here's Tones on Tail with a really wild video for Go! featuring many, many classic movie and animation clips that seem to dwell on the...um...tail. I saw Claudette Colbert, Elvis, Lorne Greene, Gary Cooper, John Wayne, Kathryn Grayson, Howard Keel, Betty Page (gulp!) and a roaring finale from Betty Boop. Who did you see?

Enjoy your turkey day all!

Monday Nov 16, 2009

Make REST Calls from OpenSSO Client SDK on the Video Phone

A new attribute has been added to the Advanced properties to support REST policy calls from the Client SDK to the new Entitlement Service. The com.sun.identity.policy.client.useRESTProtocol property is added to the Advanced -> Custom Properties section of the agent profile with a value of true to enable REST interface calls. If the property is not defined, the value defaults to false. Currently, this property is specific to J2EE agents as web agents do not use REST calls to get policy decisions.

So, yes, I planned to use the new Beyonce song Video Phone (see title) but something about this video (featuring Lady Gaga) is - how shall I say - ridiculous? No music, no melody, no thing - just videeeoooo phone and the same dance moves we've seen in every other Beyonce video. So rather than embedding that trash, here's Annie Golden (of The Shirts and Hair movie) singing Hang Up The Phone. Even in its blurry state this video has more class. And that's the truth.

Sunday Nov 15, 2009

Configuring Identity Manager Password Reset with OpenSSO NOW

The following information concerns extending the end user password reset or forgot password feature to include Identity Manager 8.1.0.5 to be released sometime in October. (I wrote this weeks ago but forgot to publish it.) In a deployment that has both products integrated, a user needs the option to change or reset a configured password. To allow for identification, challenge questions should be configured for each user account. Unless these questions are answered correctly, this behavior will not be allowed. The flow diagram below details the process. (Right click it to open it full size in a new tab or window.)

To enable this feature, you will need to configure OpenSSO and then test the configurations. The configurations will work if the user has already configured challenge questions and answers or whether the user needs to configure challenge questions and answers now. The following sections have more information.

Configuring OpenSSO

To configure OpenSSO, you will define Identity Manager URIs as not enforced for the policy agent. You will also need to modify the OpenSSO login page so that it will display a Forgot Password button.

To Define Identity Manager URLs as Not Enforced

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/\*
    • /idm/authutil/\*?\*
  6. Click Save.
  7. Logout of OpenSSO.

Modifying the OpenSSO Login Page

There are two options to consider when deciding how to display a Forgot Password button on the OpenSSO login page. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. Open Login.jsp in an editor and add the five (5) sections of code displayed in yellow in forgot_pwd.html on the OpenSSO web site.
    The URL in one section of this page that ends .../idm/authutil/questionLogin.jsp?accountId= links to the Identity Manager JSP that will be displayed if the user does not have challenge questions configured. Replace the beginning of this URL (http://am-v490-01.red.iplanet.com:6480/idm/authutil/questionLogin.jsp?accountId= in the file) with the specifics of your deployment.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under the glassfish-home/domains/your-domain/generated/ directory.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip directory to access the sample Login.jsp.
  2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
    You can search for the string /idm to locate the URLs.
  3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
    If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
    • You will lose any custom changes made to the existing Login.jsp.
    • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated.
  5. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Test The Configurations

  1. Access an Identity Manager URL.
    You will be redirected to the OpenSSO login page.
  2. Enter a username and click the "Forgot Password" button.
    You will be redirected to the Identity Manager questionLogin.jsp.
  3. Enter answers to the challenge questions and click the "Login" button.
    You will be redirected to second page.
  4. Enter your new password on this second page.
    This is a temporary password you would've received from contacting the help desk. See the process flow diagram above.
  5. Select the option to update all resource accounts.
    Ensure that both the Identity Manager and OpenSSO resources are selected.
  6. Select the option in the column "Forgot Old Password?" for the OpenSSO Resource.
  7. Click the "Change Password" button.
    The password is now changed. Use the new password next time you log in.

I had to come up with a video for this older post so I just clicked around and found this Queen video, Don't Stop Me Now. I saw this tour at MSG - leather and all!

Friday Nov 13, 2009

The JSON Schema Behind the Entitlements Service

What better day than Friday the 13th to write about the JavaScript Object Notation (JSON) schema used by the Entitlements Service to write the privilege objects returned by Those Darlin'OpenSSO REST Policy Evaluation Interfaces. JSON is relatively easy to read and understand. According to Introducing JSON, it is easy for machines to parse and generate...and is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. (Check out the link for more information.)

An Entitlements Service privilege object has the following attributes:

  • description is a descriptive string.
  • entitlement is made up of:
    • name (any arbitrary unique String)
    • application name
    • set of action values (String to boolean)
    • list of resource names
    • a list of exclusive resource names
  • subjects can include one or more entitlement subjects; in that case, logical subjects such as OrSubject and AndSubject are used. Please refer to sub section, Sub ject JSON Representation for schema for the support sub jects.
  • conditions can include one or more conditions; in that case, logical conditions such as OrCondition and AndCondition are used. Please refer to sub section, Condition JSON Representation for schema for the support conditions.
  • attributes may include user and static attributes.

There's more information to come but, in the meantime, here's another Jason - the Friday the 13th kind - in He's Back - The Man Behind the Mask. I don't know what's scarier the video (filled somewhat with oozing Karo Syrup) or this 80s-induced track sung by Alice Cooper. Mwahahahahahahahaha!!!!

Wednesday Nov 11, 2009

A Wonderful Use of Fedlet with Access Manager 7.1

Vimal P., Sun quality assurance engineer extraordinaire, has joined the blogosphere with his first post (well, second if you count the Hello, World test). Here's Vimal's one line description:

This blog describes how to setup the Single Sign On between Access Manager 7.1+ SAMLv2plugin acting as IDP and OpenSSO fedlet as SP.

So, jump from my part of the blogosphere world to Vimal's entry called How to Use Fedlet with Access Manager 7.1+ to learn how it's done. But first luxuriate in the sanguine tones of Louis Armstrong performing What A Wonderful World.

True to Enable Resource Authentication for OpenSSO Policy Agents

The new resource authentication feature (as documented Resource Authentication Type in OpenSSO Express 8) can also be enabled for deployments that use OpenSSO policy agents - either Web Agents or J2EE Agents. To enable resource authentication, a URL in the agent profile must be modified by appending to it the resource=true query parameter. The attribute that contains this URL is dependent upon whether the policy agent is configured in Cross Domain SSO (CDSSO) or not.

The procedure requires appending the "resource=true" query parameter to the "OpenSSO Login URL" or "CDSSO Servlet URL" field as follows:
  1. Log into the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the name of the appropriate realm.
  4. Click the Agents tab.
  5. Click the appropriate agent tab (Web or J2EE).
  6. Click the name of the agent profile to modify.
  7. Choose the appropriate sub step based on whether the agent is configured in CDSSO mode or not.

    • For an agent running in CDSSO mode, click the SSO tab and append resource=true to the existing value of the CDSSO Servlet URL attribute. For example, http://opensso.sun.com:8080/opensso/cdcservlet?resource=true.
    • For an agent NOT running in CDSSO mode, click the OpenSSO Services tab and append resource=true to the existing value of the OpenSSO Login URL attribute. For example, http://opensso.sun.com:8080/opensso/UI/Login?resource=true.

As Spandau Ballet once sang so beautifully, it's True.

Tuesday Nov 10, 2009

Those Darlin' OpenSSO REST Policy Evaluation Interfaces

Piggybacking on the information in The OpenSSO REST Interfaces in Black / White, OpenSSO Express 9 will mark the release of the RESTful interfaces for policy evaluation. All of them support both HTTP GET and POST actions, and some of them return JavaScript Object Notation (JSON) objects. The format of the OpenSSO REST URL is:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/OpenSSO-REST-interface?parameter1=value1&parameter2=value2&parameterN=valueN

NOTE: If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

The following sections contain information on invoking the available OpenSSO REST policy evaluation interfaces.

Evaluating a Decision for One Resource

The decision RESTful policy evaluation interface returns a plain text string of deny or allow in regards to a request for access. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • action defines the action to be evaluated.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?action=GET&resource=http://www.example.com/index.html&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

Evaluating a More Specific Decision for One Resource

The entitlement RESTful policy evaluation interface returns a list of JSONEntitlement objects in regards to a request for access to a resource. Although similar to the decision interface, it does allow more information to be returned as a JSON privilege object. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resource=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. But, demo does not have access permission to http://www.example.com because the IP address does not fall within the range of 192.122.18.1 and 192.122.18.254.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com"
       }
   }
}

Evaluating a Decision for Multiple Resources

The decisions RESTful policy evaluation interface returns a list in the form of a JSONEntitlements object in regards to a request for access to a set of resources. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resources defines the set of resources to be evaluated. More than one resources parameter may be added to the URL.
  • application defines the (application or application type). This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?resources=http%3A//www.example.com/index.html&resources=http%3A//www.example2.com/index.html&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. Additionally, demo (the OpenSSO demo user) has POST and GET permission for http://www.example.com and GET permission for http://www.example2.com.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
             "POST":true,
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example2.com"
       }
       ]
   }
}

Evaluating a Decision for A Root and Sub Tree Resources

The entitlements RESTful policy evaluation interface returns a list in the form of a JSONEntitlements object in regards to a request for access to root resource and its (multiple) sub resources. For example, given the root resource of http://www.example.com, results for all sub resources (including http://www.example.com/hr/\*, http://www.example.com/eng/\* and http://www.example.com/sales/\*) will be returned. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the root of the set of resources to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resources=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

The following result signifies that the evaluation has approved the request for access. But, demo (the OpenSSO demo user) has POST and GET permission only for http://www.example.com/hr/\* and http://www.example.com/engr/\*.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/hr/\*"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/engr/\*"
       }
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com/sales/\*"
       }
   }
}

Now enjoy the musical and illustrative (?) accomplishments of Those Darlins with Red Light Love. It's dope. And that's a good thing!

Thursday Nov 05, 2009

Harden OpenSSO By Disabling ssoadm.jsp

Notwithstanding that it is still a secret, we've just added a property that allows you to disable the ssoadm.jsp to harden your system and reduce attack vectors. The property is ssoadm.disabled and can be added with a value of true to the Advanced properties.

  1. Log into the OpenSSO console as administrator.
  2. Click the Configuration tab.
  3. Click the Servers and Sites tab.
  4. Click the Server name in the Servers table.
  5. Click the Advanced tab.
  6. Click Add in the Advanced Properties table.
  7. Enter ssoadm.disabled as the Property Name and true as the Property Value.
  8. Click Save.

You can also add this property as a default setting for future server configurations by clicking the Default Server Settings button under the Servers and Sites tab.

And now here's the only song that I know of that uses the word harden. The video is a live performance of Quarterflash singing (and playing saxophone on) Harden My Heart.

Monday Nov 02, 2009

Switch On Switch Off OpenSSO SAMLv2 Services

Currently, the SAMLv2 Service servlets are always listening. For example, if you don't want to use the Artifact Resolution Service or the Manage Name ID Service it is still on. To switch the services off, you can remove the endpoints from the entity provider's configuration.
  1. Log into the OpenSSO console as administrator.
  2. Click the Federation tab.
  3. Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
  4. Click the Services tab.
  5. Remove the appropriate endpoint.
  6. Click Save.
You can also use the ssoadm command line interface.
  1. Use ssoadm export-entity to export the extended metadata.
  2. Modify the exported extended metadata.
  3. Use ssoadm delete-entity to delete the original extended metadata.
  4. Use ssoadm import-entity to import the modified extended metadata.
Disabled services return an HTTP error code.

Interestingly enough, after I titled this entry using the B-Movie single Switch On Switch Off, I was unable to find a video for that song anywhere. (It was a failed single but really this IS the internet.) In absentia, here is B-Movie's biggest hit (of which there are plenty of videos) Nowhere Girl.

3743

Tuesday Oct 20, 2009

Someone Needs a ヴァケイション

Someone (who shall remain nameless) did the unthinkable and changed the status of the / Top Level Realm to inactive. After doing this, someone could no longer log in to the console. So how did someone rectify this situation?

Someone used an LDAP browser, found the ou=services,dc=opensso,dc=java,dc=net field and changed the value back. Now remember...don't actually do this but at least there is a way to undo it.

And now here's Connie Francis singing her hit Vacation in Japanese. Who knew?

Tuesday Oct 13, 2009

Cool Changes to the OpenSSO Console

Some new attributes have been added to the OpenSSO Administration Console and are available now in the nightly builds.
  1. Prompt User for Old Password is a flag that will do just that - add a text field to the Change Password page that would require a user to enter the old password when changing it. The attribute is located under the top level Configuration tab. Underneath the Configuration tab, click the Console tab and then the Administration link. It is in the Realm Attributes section.
    If not checked, the old password will not be required. This is the default behavior. If checked, the behavior is dependent upon whom is changing the password: the administrator or the end user.

    • If an administrator is changing the password for the end user, the old password is not required. The Prompt User for Old Password text field will be grayed out and the password will be changed by calling the getIdentity method in com.sun.identity.idm.IdUtils.
    • If the end user is changing the password on their own, the old password will be required. The Prompt User for Old Password text field will be enabled and, after it has been entered, the password will be changed by calling the changePasswordmethod in com.sun.identity.idm.AMIdentity.
  2. Requested Key Type allows you to define the key system used by the STS Client profile defined; for example, the default SecurityTokenService. The attribute is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab. Click the name of the profile you are configuring to see the attribute under the Security section.
    You can choose Public Key (two keys are used - one to encrypt the data and one to decrypt the data) or Symmetric Key (one key is used to encrypt and decrypt the data).
  3. A SAML Configuration section has been added to the STS Client and Web Service Client agent profiles to help configure the SAMLv2 protocol. (The section already exists for the Web Service Provider agent profile.) The section is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab or the Web Service Client tab. Click the name of the profile you are configuring to see the SAML Configuration section link. The section includes the following attributes.

    • SAML Attribute Mapping: This configuration maps the SAML attribute in an assertion from an incoming web service request to an attribute that would be fetched from either an authenticated OpenSSO SSOToken or the configured OpenSSO identity data store. The SAML attribute would be placed in the Attribute Statement created by the Security Token Service for a web service provider. The format is SAML_attr_name=OSSO_attr_name where SAML_attr_name is the SAML attribute name in the assertion from an incoming web service request and OSSO_attr_name is the attribute name that is fetched from OpenSSO.
    • SAML NameID Mapper Plugin: This attribute defines the NameID mapper plug-in class to be used for SAML account mapping.
    • SAML Attributes Namespace: This attribute defines the name space used to qualify SAML attributes and elements.
    • Include Memberships: If enabled, this attribute specifies that the principal's membership data must be included in the assertion as a SAML attribute.

Now here's Cool Change from Little River Band.

Thursday Oct 08, 2009

The OpenSSO REST Interfaces in Black / White

A RESTful web service assumes all components are exposed using the same, uniform application interface. (An interesting article on other requirements of REST can be read here.) From this high-level HTTP accomplishes this uniformity with its methods such as GET and POST. Thus calling a RESTful web service requires the simple construction of a URL.

OpenSSO exposes a number of interfaces that support a REST architecture. These operations are supported out of the box so no special configurations are required. The format of the URL is:

http://OpenSSO-host:OpenSSO-port/opensso/identity/OpenSSO-REST-interface?parameter1=value1&parameter2=value2&parameterN=valueN

NOTE: If the value of the parameters (value1, value2, ..., valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

The following sections contain information on invoking the available OpenSSO REST interfaces.

Authentication

The authenticate REST interface opens an HTTP connection to authenticate a user with a POST operation. The following URL defines a username and password that will be authenticated at the OpenSSO root realm - by default, / (Top Level Realm).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning

You can also add the optional uri parameter to the URL. The value of this parameter would be one or more of the URL parameters documented in Accessing the OpenSSO Enterprise Authentication Service User Interface with a Login URL. For example, the following URL will authenticate the user to a specific sub realm.

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name

You can define additional parameters. For example, the following URL will authenticate the user to a specific sub realm using the specified authentication chain (ldapService, for example).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name&service=ldapService

After successful authentication, a token string is returned to represent the authenticated user for other REST operations. Various exceptions might also be thrown such as UserNotFound and InvalidPassword. A generic exception is provided if unable to reach OpenSSO or for other fatal errors.

NOTE: The token string returned is also applied as the value of the subjectid in some OpenSSO REST operations like logout and authorize.

Token Validation

The isTokenValid REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.

http://OpenSSO-host:OpenSSO-port/opensso/identity/isTokenValid?tokenid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#

The operation returns a value of true or false.

Logout

The logout REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.

http://OpenSSO-host:OpenSSO-port/opensso/identity/logout?subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#

The operation invalidates the tokenid and logs the user out.

Authorization

The authorize REST interface will verify against created policies that the user is authorized to perform a particular operation (GET or POST) on a particular HTTP resource. The following URL defines a user (subjectid) that wants to POST (action) to the specified resource (uri).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authorize?uri=http://www.sun.com:90&action=POST&subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=@AAJTSQACMDE=#

The operation returns a value of true or false. If the user is not authorized, an exception is thrown. Assuming a policy has been created to allow authenticated users to POST to the defined resource (in this case, http://www.sun.com:90), the above URL would return true.

Logging

The log REST interface will log to the OpenSSO Logging Service. The URL needs to be populated with the following information.
  • appid defines the tokenid of the user with the necessary permissions to write to the log; for example amadmin.
  • subjectid defines the tokenid of the user about whom the log record is being written.
  • logname is the module name of the OpenSSO component invoking the Logging Service; for example, amAuthentication.
  • message is the data being logged.

An example URL is:

http://OpenSSO-host:OpenSSO-port/opensso/identity/log?appid=AQIC5wM2LY4Sfcz24GvZCdv6ie9dTJBa3Co7Rn2QUjKCDuM=@AAJTSQACMDE=#&subjectid=AQIC5wM2LY4SfcwTCcRKSDXEsiJXt71PDAUmN1bm/draPZI=@AAJTSQACMDE=#&logname=amAuthentication&message=test

Searching Identity Types

The search REST interface will search the configured database for particular identities. The URL needs to be populated with the following information.
  • filter defines a set of criteria that controls what is returned by the operation.
  • attributes_name defines one or more LDAP attributes for which to search.
  • attribute_values_value-of-attributes_name defines the value of the attribute (defined by attributes_name) that is being searched.
  • admin defines the tokenid of the user with the necessary permissions to search; for example amadmin.

The following URL would return the available agent types; by default string=wsc, string=wsp, and string=SecurityTokenService.

http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=\*&attributes_names=objecttype&attributes_values_objecttype=agent&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

This example would return all user entries.

http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=\*&attributes_names=objectclass&attributes_values_objectclass=person&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

Display Identity Data

The attributes REST interface will search the configured database for identity information about the defined subjectid. It retrieves roles and common attributes (including first name and last name) and is used by applications to obtain a user's profile for application-controlled authorization. Optionally, the URL can take one or more attribute_names parameters to define which attribute values will be returned; if attribute_names is not defined it would return all the attributes in the profile. This is an example URL that would return the specified user's LDAP profile.

http://OpenSSO-host:OpenSSO-port/opensso/identity/attributes?attributes_names=uid&subjectid=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#

The URL might return something like this:
userdetails.token.id=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#
userdetails.attribute.name=sn
userdetails.attribute.value=jning
userdetails.attribute.name=cn
userdetails.attribute.value=jning
userdetails.attribute.name=objectclass
userdetails.attribute.value=sunFederationManagerDataStore
userdetails.attribute.value=top
userdetails.attribute.value=iplanet-am-managed-person
userdetails.attribute.value=iplanet-am-user-service
userdetails.attribute.value=organizationalperson
userdetails.attribute.value=inetadmin
userdetails.attribute.value=iPlanetPreferences
userdetails.attribute.value=person
userdetails.attribute.value=inetuser
userdetails.attribute.value=sunAMAuthAccountLockout
userdetails.attribute.value=sunIdentityServerLibertyPPService
userdetails.attribute.value=inetorgperson
userdetails.attribute.value=sunFMSAML2NameIdentifier
userdetails.attribute.name=userpassword
userdetails.attribute.value={SSHA}XhiE0RMwO/D7SSQ5fYLrTlFjmbHmYbQkIU43FA==
userdetails.attribute.name=uid
userdetails.attribute.value=jning
userdetails.attribute.name=givenname
userdetails.attribute.value=jning
userdetails.attribute.name=inetuserstatus
userdetails.attribute.value=Active

Display Particular Identity Data

The read REST interface will search the configured database for particular identity information about the LDAP user defined by name. The attributes_names parameter defines one or more LDAP attributes for which to search. This is an example URL that would return the specified user's LDAP profile.

http://OpenSSO-host:OpenSSO-port/opensso/identity/read?name=jning&attributes_names=uid&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

The URL might return something like this:
identitydetails.name=jning
identitydetails.type=user
identitydetails.realm=dc=opensso,dc=java,dc=net
identitydetails.attribute=
identitydetails.attribute.name=uid
identitydetails.attribute.value=jning

Creating Identity Types

The create REST interface will create the defined identity type in the configured data store. The URL needs to be populated with the following information. Note the values for these parameters in the sample URLs below.
  • identity_name defines a easily-readable name for the identity.
  • identity_attribute_names defines one or more LDAP attributes to be created for the identity.
  • identity_attribute_values_value-of-identity_attribute_names defines the value of the attribute (defined by attributes_name) being created.
  • identity_realm defines the realm in which the identity is created.
  • identity_type defines the type of identity being created.
  • admin defines the tokenid of the user with the necessary permissions to create; for example amadmin.

This URL would create a user type. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=rest_user&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=sn&identity_attribute_values_sn=sn_of_rest_user&identity_attribute_names=cn&identity_attribute_values_cn=cn_of_rest_user&identity_realm=/&identity_type=user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

The following URL would create a web agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=webagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=WebAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://web-agent-host:web-agent-port/opensso

The following URL would create a J2EE agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=j2eeagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=J2EEAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://J2EE-agent-host:J2EE-agent-port/opensso&identity_attribute_names=AGENTURL&identity_attribute_values_AGENTURL=http://OpenSSO-host:OpenSSO-port/opensso

The following URL would create a 2.2 agent profile. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=webagent70&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_realm=/&identity_type=Agent&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

Updating Identity Data

The update REST interface will update an identity with the information defined in the URL. The following URL would update the user profile with an email address.

http://OpenSSO-host:OpenSSO-port/opensso/identity/update?identity_name=rest_user&identity_attribute_names=mail&identity_attribute_values_mail=restUser@rest-DOT-org&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

Use the read REST interface to verify the update.

Deleting an Identity Profile

The delete REST interface will remove the identity profile (defined as the value of the identity_name parameter) from the user data store. The following URL would delete the rest_user profile previously created.

http://OpenSSO-host:OpenSSO-port/opensso/identity/delete?identity_name=rest_user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#&identity_type=user

Use the search REST interface to verify the deletion.

Now check out the not-most-recent-single-but-still-great-video from The Raveonettes: Black / White.

Tuesday Sep 29, 2009

Don't Be Tardy: Configure Password Expiration with OpenSSO and Identity Manager

In a deployment architecture that includes OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October) it is possible to configure user password reset based on the password's expiration date, or a help desk administrator's action. In the former use case, when a password is close to expiration, the user data store (which must be an LDAP directory server) can send a warning to the user based on the time configured in the assigned password policy. Upon accessing a resource protected by OpenSSO, the user would be redirected to Identity Manager to change the password. The URL of the protected resource is saved as a value of the goto parameter and the user will be redirected to this location after changing the password.

For the latter use case, if the user allows the password to expire, a help desk administrator can initiate the reset of the expired password by flagging the account and adding a temporary password to the user's profile. The administrator will then communicate the temporary password to the user (by email, for example). Upon logging into OpenSSO with this temporary password, the user will be directed to Identity Manager where the password is reset and the flag is removed.

The procedures documented will enable these use cases. Note that they only support the LDAP authentication module. The following sections contain the configuration procedures.

Configuring the LDAP Directory Server

For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls related to password expiration set:
  • Set Password Expiration (LDAP attribute: passwordexp, passwordmaxage)
  • Set Expiration Warning (LDAP attribute: passwordwarning)
  • Warning Duration (LDAP attribute: passwordExpireWithoutWarning)
It should also have the following controls set to allow for administrator-driven password reset:
  • Require Password Change at First Login and After Reset (LDAP attribute: passwordchange, passwordmustchange)
  • Allow Users to Change Their Passwords (LDAP attribute: pwdallowuserchange)
The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory server for instructions on how to do these configurations.

Configuring OpenSSO

Only the OpenSSO LDAP authentication module supports the password change controls enforced by most directory servers. The following sections contain OpenSSO configurations.

To Enable LDAP Authentication

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name.
  4. Click the Authentication tab.
  5. Click New in the Authentication Chaining section to create a new authentication chain.
  6. Enter a name for the chain and click OK.
    For this example use idmauth.
  7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
  8. Click Back to Authentication.
  9. Select the service just created as the value for Organization Authentication Configuration.
  10. Click LDAP in the Module Instances section.
  11. Customize the LDAP properties to reflect your directory - at minimum:
    • Primary LDAP Server
    • DN to Start User Search
    • DN for Root User Bind
    • Password for Root User Bind
    • Password for Root User Bind (confirm)
  12. Save the changes.
  13. Logout from the OpenSSO console.
Note: Following this configuration:
  • Use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.
  • Login to the Identity Manager console and expand the OpenSSO resource listing to view the OpenSSO objects. If you receive an error, you may need to reconfigure the OpenSSO adaptor to use a delegated administrator rather than amadmin to connect to OpenSSO. The Identity Manager adaptor for OpenSSO authenticates to OpenSSO using the authentication configuration for the realm which is now different from the configuration for the OpenSSO console. Thus, amadmin will no longer work. See Delegating Administrator Privileges for information on delegating administrative privileges to a group.

To Define Identity Manager URLs as Not Enforced

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/\*
    • /idm/authutil/\*?\*
  6. Click Save.
  7. Logout of OpenSSO.

To Create ChangePassword.jsp

This procedure documents how to create ChangePassword.jsp, a custom JSP for redirecting a user to Identity Manager for password change events. (By default, the user would be directed to the OpenSSO password change page.) ChangePassword.jsp will forward the following information to Identity Manager:
  • The original URL requested by the user and defined as the value of the goto parameter.
  • The user identifier defined as the value of the accountId parameter

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample ChangePassword.jsp.
  2. Modify the Identity Manager URL in the JSP based on your deployment.
  3. Copy ChangePassword.jsp to /web-container-deploy-base/opensso/config/auth/default/ and to /web-container-deploy-base/opensso/config/auth/default_en/.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.

Modifying the LDAP Authentication Module XML Service File

This procedure documents how to modify LDAP.xml to use ChangePassword.jsp. There are two options to consider when deciding how to modify LDAP.xml. You can manually change the deployed LDAP.xml file, or you can use the sample LDAP.xml included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify a Deployed LDAP.xml
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed LDAP.xml page.
  2. Open LDAP.xml in an editor and add the section of code displayed in yellow in admin_pwd_reset_ldap.html on the OpenSSO web site.
  3. Change to the /web-container-deploy-base/opensso/config/auth/default_en/ directory to access the second copy of LDAP.xml and make the same change.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
To Use the Sample LDAP.xml

  1. Change to the opensso/integrations/idm/xml/ directory in the decompressed opensso.zip to access the sample LDAP.xml.
  2. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/LDAP.xml with the sample LDAP.xml in two directories:
    • /web-container-deploy-base/opensso/config/auth/default/
    • /web-container-deploy-base/opensso/config/auth/default_en/
    If you replace your existing LDAP.xml with the sample LDAP.xml you will lose any custom changes made to the existing LDAP.xml.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code to save the URL value of the goto parameter in the HTTP request. This saved URL is required by the ChangePassword.jsp. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.

There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in admin_pwd_reset_login.html on the OpenSSO web site.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
    You can search for the string /idm to locate the URLs.
  3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
    If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
    • You will lose any custom changes made to the existing Login.jsp.
    • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Testing The Configurations

Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.

A. Testing Password Warning Expiration

Perform the following actions after the time the password expiration warning, as defined in the password policy, would take effect.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. Enter the test user name and password.
    You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
    • The URL is the one configured in ChangePassword.jsp.
    • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
    • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.

B. Testing Password Expiration

Perform the following actions after the time the password should have expired, as defined in the password policy.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. Enter the test user name and password.
    An error page is displayed informing the test user that the password has expired. The user will be instructed to have the administrator reset the password.

C. Testing Administrator Password Reset

  1. Refer to your directory server documentation to enable audit and logging.
    Monitor the directory server audit log as you finish the test.
  2. Login as the directory administrator and change the password for a test user.
    This simulates the password reset by a help desk administrator.
  3. Verify that the user's userPassword attribute was modified and the pwdreset was set to TRUE using the audit log.
    The pwdreset attribute will force the user to change the password at the next login. The audit log might resemble this sample.
    time: 20090713074720
    dn: uid=idmuser1,dc=sun,dc=com
    changetype: modify
    replace: userPassword
    userPassword: {SSHA}4Bgy/HF9SGN9nnS4Ii6/KJj9ktFdAxQUIDvwVQ==
    -
    replace: modifiersname
    modifiersname: cn=admin,cn=administrators,cn=dscc
    -
    replace: modifytimestamp
    modifytimestamp: 20090713144720Z
    -
    replace: passwordexpirationtime
    passwordexpirationtime: 19700101000000Z
    -
    replace: pwdreset
    pwdreset: TRUE
    
  4. Access the Identity Manager user URL.
    You will be redirected to OpenSSO for login.
  5. Enter the test user name and password.
    You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
    • The URL is the one configured in ChangePassword.jsp.
    • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
    • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.
For those fans of The Real Housewives of Atlanta, here's a fan-made video of Kim Zolciak's (Don't Be) Tardy for the Party. (I added the parentheticals to make it seem official.) Kandi Burress produced a dance floor smash for the woman who can not sing! Who knew?

Sunday Sep 27, 2009

Configuring Self Unlock After Account Lockout Using OpenSSO and Identity Manager is Fun

User account lockout in OpenSSO can happen in either of the following ways:
  • Memory account lockout occurs when the user has exceeded the allowed number of failed attempts to log in as configured in the password policy. The user may remain locked out for a set period of time and can only reset the password after that period has passed. The locked state of the user account is maintained in memory and no information is written to the user's LDAP profile.
  • Physical account lockout occurs when the status of a specified LDAP attribute in the user’s profile is explicitly changed to Inactive, either by an administrator or as a result of some automated processes. (The specified LDAP attribute is defined as the value of the Lockout Attribute Name attribute in the Core authentication module.) By default it is inetuserstatus.
When a user's account is locked, it is possible to allow the user to unlock the account without intervention from an administrator. The procedures documented will enable this for a deployment with OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October). Note that memory account lockout in OpenSSO must be disabled using the OpenSSO console as the account lockout controls in the user data store will be used. Using this feature in a deployment with OpenSSO and Identity Manager only supports the LDAP authentication module. The following sections contain the configuration procedures.

Configuring the LDAP Directory Server

For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls set:
  • Enable Account Lockout (LDAP attribute: passwordLockout)
  • Failures Before Lockout (LDAP attribute: passwordMaxFailure)
  • Failure Count Reset (LDAP attribute: passwordResetFailureCount)
  • Set Limit on Lockout Duration (LDAP attribute: passwordUnlock)
  • Lockout Duration (LDAP attribute: passwordLockoutDuration)
The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory for instructions on how to do these configurations.

Configuring OpenSSO

The OpenSSO LDAP authentication module supports the account lockout controls enforced by most directory servers. The following sections contain OpenSSO configurations.

To Enable LDAP Authentication

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name.
  4. Click the Authentication tab.
  5. Click New in the Authentication Chaining section to create a new authentication chain.
  6. Enter a name for the chain and click OK.
    For this example use idmauth.
  7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
  8. Click Back to Authentication.
  9. Select the service just created as the value for Organization Authentication Configuration.
  10. Save the changes.
  11. Logout from the OpenSSO console.
Note: Following this configuration, use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.

To Define Identity Manager URLs as Not Enforced

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/\*
    • /idm/authutil/\*?\*
  6. Click Save.
  7. Logout of OpenSSO.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code for this use case. The code will save the value of the goto parameter in the HTTP request. This saved URL is required by the user_inactive.jsp created in the next procedure. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.

There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_login.html on the OpenSSO web site.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
    You can search for the string /idm to locate the URLs.
  3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
    If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
    • You will lose any custom changes made to the existing Login.jsp.
    • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Modifying the OpenSSO Account Lockout Message Page

This procedure documents how to modify user_inactive.jsp, the JSP that notifies the user that the account is locked. You will modify the page to include a redirect to an Identity Manager page that will enable the user to unlock the account. user_inactive.jsp will forward the following information to Identity Manager:
  • The original URL requested by the user and defined as the value of the goto parameter.
  • The user identifier defined as the value of the accountId parameter

There are two options to consider when deciding how to embed code into the OpenSSO user_inactive.jsp. You can manually change the deployed user_inactive.jsp file, or you can use the sample user_inactive.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify the Account Lockout Message Page
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed user_inactive.jsp page.
  2. Open user_inactive.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_inactive.html on the OpenSSO web site.
    Embedded in the JSP, you will see the URL to the Identity Manager page that allows the account unlock. You should modify this URL as per your deployment.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
Note: The Identity Manager URL used in the sample refers to anonResetPassword.jsp. You might, however, direct the user to questionLogin.jsp, the forgotten password page because if a user has accidentally locked an account it may be because of a forgotten password.

To Use the Sample Account Lockout Message Page

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample user_inactive.jsp.
  2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
    You can search for the string /idm to locate the URLs.
  3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/user_inactive.jsp with the sample user_inactive.jsp.
    If you replace your existing user_inactive.jsp with the sample user_inactive.jsp the following will occur.
    • You will lose any custom changes made to the existing Login.jsp.
    • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Testing The Configurations

The following procedures document testing these configurations for memory account lockout and physical account lockout.
To Test Memory Account Lockout
  1. Configure the password policy and assign the policy to the test user.
    This is done using the user data store.
  2. Access a resource protected by OpenSSO to get redirected to the login page.
  3. Login to OpenSSO using an incorrect password.
    Do this consecutively until the account gets locked and the error page is displayed. This will be dependent on the number of attempts configured in the password policy.
  4. Click the hyperlink on the page.
    You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
  5. Change your password.
    Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.
To Test Physical Account Lockout
  1. Set the value of the inetuserstatus attribute in the test user's profile in the user data store to Inactive.
  2. Access a resource protected by OpenSSO to get redirected to the login page.
  3. Login to OpenSSO.
    An error page will be displayed informing you that the account has been locked.
  4. Click the hyperlink on the page.
    You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
  5. Change your password.
    Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.

And now here are some girls doing it for themselfes: Cyndi Lauper, Ann Wilson, Nancy Wilson, Wynona Judd, Amy Grant and Destiny's Child (Beyonce, Kelly Rowland and Michelle Williams) performing a live version of Hey Now (Girls Just Wanna Have Fun).

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today