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?

About

docteger

Search

Categories
Archives
« December 2009 »
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
10
11
12
13
14
16
17
18
19
20
23
24
25
26
27
28
29
30
31
  
       
Today