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.

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?

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
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