Tuesday Jan 26, 2010

Eyes Only: OpenSSO Express 9 Documentation

In anticipation of the release of OpenSSO Express 9, we've uncovered the documentation. The Parent Page for OpenSSO Express 9 contains links to wiki articles you may not (or may ;>) have seen including:
  • Authenticating to the OpenSSO Express 9 Monitoring Service
  • Configuring the OpenSSO Express 9 Java Fedlet for XACML Query
  • More Entitlements Service Subcommands and Options for the ssoadm Command Line Interface in OpenSSO Express 9
  • Deploying OpenSSO Express 9 on an IBM WebSphere Application Server 7.0 Web Container
  • OpenSSO Express 9 MIB File for Monitoring Service
  • Rebuilding the Indexes for an Embedded OpenDS Data Store in OpenSSO Express 9
  • XACML Subcommands and Options for the ssoadm Command Line Interface in OpenSSO Express 9
  • Implementing ASP.NET Fedlet Single Logout with OpenSSO Express 9
  • Introducing the OpenSSO Express 9 Entitlements Service REST Interfaces
  • New Functionality for the OpenSSO Express 9 Java Fedlet
  • New Functionality for Web Services Security in OpenSSO Express 9
  • New Functionality in the OpenSSO Express 9 Standard and Beta Administration Consoles
  • Using the OpenSSO Express 9 REST Privilege Management Interfaces
  • Introducing the OpenSSO OAuth Token Service (Express 9 Early Access)
  • Rebuilding the OpenDS Indexes for a Remote User Data Store in OpenSSO Express 9
  • Using Microsoft Active Directory 2008 as the OpenSSO Express 9 User Data Store
  • Using the OpenSSO Express 9 REST Listener Management Interfaces
  • Using the OpenSSO Express 9 REST Policy Evaluation Interfaces
Now check out Sheena Easton singing the James Bond theme, For Your Eyes Only.

Thursday Jan 21, 2010

Sun & Oracle: EU Has No More Tears

The European Union cleared Oracle's acquisition of Sun this morning.

At the same time, Barbra Streisand and Donna Summer cleared the release of this tape of the two singing No More Tears (Enough is Enough). It's a capella and direct from the studio.

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.

Friday Jan 15, 2010

Managing OpenSSO Entitlements Using REST: The End

This is the fourth and final part (the end) 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 three is Evaluating OpenSSO Entitlements Using REST.

With the upcoming release of OpenSSO Express 9, REST interfaces in the form of URLs have been developed to search, get, add, modify and remove Entitlement Service privileges (policies). The privilege management interfaces support both HTTP GET, PUT, DELETE, and POST actions, and return JavaScript Object Notation (JSON) objects.

The privilege management URLs begin with the base which can be 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 privilege management URL is:

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

To search for a privilege or add a new configuration, use the base URL (http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/privilege/), replace OpenSSO-REST-string with the appropriate privilege name, and append 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.

The following sections contain more information.

Searching for Privileges

The privilege interface uses HTTP GET to return a JSON string that lists the configured privileges under a particular realm; by default, the / Top Level Realm is searched. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • filter defines criteria to narrow down the privileges searched. For example, if there are privileges named as a1, a2, b1 and b2, the filter name=a\* would narrow the search to privileges that begin with a. The default value is name=\*.
For example:

http://www.example.com:8080/opensso/ws/1/entitlement/privilege? 
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&filter=name%3Da\*
This REST call returns a JSON string. The example below means that there is a privilege named example1 under the top level realm.
{ 
   "statusCode":200, 
   "statusMessage":"OK", 
   "body":{ 
      "result":[ 
         "example1" 
      ] 
    } 
}

Adding a New Privilege

The privilege interface also uses HTTP POST to add a JSON representation of the defined privilege to the Entitlement Service under a particular realm; by default, the / Top Level Realm. The URL may be populated with the following information.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • privilege.json defines the privilege configuration as a JSON representation.
For example:

http://www.example.com:8080/opensso/ws/1/entitlement/privilege?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP POST.
POST /opensso/ws/1/entitlement/privilege HTTP/1.1

subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

It returns a JSON string representing the outcome of the action. The example below means a successful POST.
{
   "statusCode":201,
   "statusMessage":"Created",
   "body":"Created"
}

Retrieving a Privilege Configuration

To get the configuration for a specific privilege, append the privilege name and parameter to the end of the URI. The interface uses HTTP GET to return a JSON representation of the defined privilege. The only parameter is the URL encoded value of the encoded token.id that defines the subject.

http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example1?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON representation of privilege example1. The example below means that the subject accessing http://www.example.com must be authenticated.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "result":"{
           \\"name\\":\\"example1\\",
           \\"description\\":\\"desciption\\",
           \\"eSubject\\":{
               \\"state\\":\\"\\",
               \\"className\\":\\"com.sun.identity.entitlement.AuthenticatedESubject\\"
           },
           \\"entitlement\\":{
               \\"name\\":\\"entitlement\\",
               \\"applicationName\\":\\"iPlanetAMWebAgentService\\",
               \\"resourceNames\\":[
                   \\"http://www.example.com/\*\\"
               ]
               \\"actionsValues\\":{
                   \\"GET\\":true
               },
           }
       }"
   }
}

Modifying an Existing Privilege

To modify the configuration of an existing privilege, append the privilege name and parameters after the URI. The interface uses HTTP PUT to modify the defined privilege based on a JSON representation used as input. The URL may be populated with the following information.
  • The privilege being modified is defined by the OpenSSO-REST-string variable of the URL. In the following example, the privilege being modified is example2.
  • subject defines the requesting user using the URL encoded value of the encoded token.id.
  • privilege.json defines the new privilege configuration as a JSON representation.
http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example2?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege
This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP PUT.
PUT /opensso/ws/1/entitlement/privilege/example2 HTTP/1.1

subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege
This REST call returns a JSON string representing the outcome of the action. The example below means a successful PUT.
{ 
   "statusCode":200, 
   "statusMessage":"OK", 
   "body":{ 
      "result":"OK" 
   } 
}

Removing an Existing Privilege

To remove an existing privilege, append the privilege name and parameter after the URI. The interface uses HTTP DELETE to remove the defined privilege. The parameter is the URL encoded value of the encoded token.id that defines the subject.

http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example2?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP DELETE.

DELETE /opensso/ws/1/entitlement/privilege/example1?subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D HTTP/1.1

This REST call returns a JSON string representing the outcome of the action. The example below means a successful DELETE.

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

I couldn't decide whether to end this series with The Doors The End or Nancy Sinatra's The End. While searching around I found that Nancy's song was being used in a television commercial so here it is (the song not the commerical) with pix of the minx herself.

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.

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