Are you pursuing changes to your Directory Services or Access Management infrastructure this year? If so, there are two resources that you want to be aware of to help understand the opportunity and impact on your organization. Eric Leach, will be presenting a webinar next week as part of the SANS Institute's Webinar series on Security. You can register for the webinar here.
Title: Smart Strategies for Securing Extranet Access When: Tuesday, March 09 at 1:00 PM EST (1800 UTC/GMT) Presenter: Eric Leach & Dave Shackleford Register here
Additionally, there was a new training course that was launched for resources interested in building a solid foundation for managing Directory Services. The course also offers an insight into the essential building blocks of access management. Additionally, it covers the use of virtual directories which is a crucial component of an enterprise identity architecture. The virtual directory can help consolidate legacy directories when companies want to reduce cost. Additionally, when time is critical for federation projects or mergers and acquisitions a virtual directory can help connect necessary identity attributes without changing code.
This foundational course on Directory Services can be found here. The course covers the following topics:
Discuss the importance, features, benefits, and functional aspects
of identity management and Oracle Identity Management products
Describe concepts associated with directories and the Lightweight Directory Access Protocol (LDAP)
Compare Oracle Internet Directory 11.1.1.1.0 and Oracle Virtual Directory 11.1.1.1.0: two Oracle Identity Management products
I’m happy to report that we’ve fixed an issue in the percent encoding step of our OAuth signature library for the Jersey framework. The issue reported was caused by the fact that we were using Java’s URLEncoder and URLDecoder classes to compute OAuth’s signature base string. Unfortunately those classes do not perform an RFC3986 compliant encoding which is required in OAuth. The main difference is that a space character will be encoded as a + when we need it to be escaped as a %20 (more info here).
To fix this, we’ve chosen to leverage Jersey’s UriComponent class. There is one notable difference though with how one would encode a URI (see here for a very detailed explanation of URIs): OAuth says that the signature base string is built by concatenating the request method, the request URL and the normalized parameters (with & to separate them) and that those elements must be encoded (prior to concatenation). In effect we are re-encoding elements that are already encoded. As Paul noted, it’s as if we wanted to pass the signature base string in a URI… I remember this possibility was mentioned in conversations about debugging OAuth deployment but that’s the only case I remember for this.
Anyway, to illustrate this, below is the piece of code where the bulk of the action happens:
StringBuffer buf = new StringBuffer(request.getRequestMethod().toUpperCase());
URI uri = constructRequestURL(request);
String tp = uri.getScheme();
buf.append('&').append(UriComponent.encode(tp, UriComponent.Type.SCHEME));
tp = uri.getAuthority();
buf.append("%3A%2F%2F").append(UriComponent.encode(tp, UriComponent.Type.AUTHORITY));
tp = uri.getPath();
buf.append(UriComponent.encode(tp, UriComponent.Type.PATH_SEGMENT));
buf.append('&').append(UriComponent.encode(normalizeParameters(request, params), UriComponent.Type.QUERY_PARAM));
Our testing code now also includes elements with spaces to make sure we got it right (thanks to Michael Werle).
Last December I posted an article about the OpenSSO's Authnicip extension module. That's the extension to issue Information Cards and Security Tokens to an Identity Selector. I said, the code doesn't compile anymore with the latest build of openinfocard and that I would try to fix it. This was easy enough, so I have done it to the best of my knowledge with no guaranty of course. However, I don't currently have the commit rights for this extension. So, until I figure that out, and for those who can't wait (I doubt it), I can send a tar file upon request.
The news arrived on teletwitter yesterday... A new open-source shop headed by Lasse Andressen- Sun's former CTO for Central & Northern Europe-was born February 1st, 2010 under the name of ForgeRock. ForgeRock is apparently providing a "home" for OpenSSO, OpenESB and Liferay portal projects with the clever intend to ramp up the security integration stack. This is good news, not surprising, and certainly bound to happen following Oracle's announcement to pull "useful" parts (i.e. Fedlet, STS, Entitlement) out of OpenSSO to feed into Oblix without clearly indicating what's next with OpenSSO and its community. ForgeRock says "to be committed to the continued open development of OpenAM (understand OpenSSO) and aims to meet Sun's original product roadmap". That's great! Coupe things puzzle me though... How on Earth can they release OpenSSO Express Build 9 (re-branded OpenAM Build 9) today since the official bits aren't released yet? Or maybe they are, only we don't know it. And second, what engineering resources will they commit to continue the development on the basis of the OpenSSO's source tree? To be followed...
This release will be the main topic on the next Belgian edition of the European OpenSSO Userdays. The event is organized by ACA IT-Solutions together with Community Builder.
Time and place : February 10th, from 8:30 AM till 12 PM at Sun Microsystems Belgium Lozenberg 15, 1932 Zaventem
The agenda includes presentations by four internationally recognized OpenSSO experts: Alan Foster, Jonathan Scudder, Steve Ferris and Victor Ake. The program includes “What’s new in OpenSSO Express 9, “Monitoring”, “Entitlements Service”, “Secure API authorization” and “Fedlet”. More information is available at http://www.aca-it.be/events
Well, my friends, it is time for me to say goodbye. It's been a wonderful 5 years at Sun. As many probably suspected, I will not be joining the Oracle Identity team.
These past five years have been the best professional experiences in my life. I had a blast working with the Java Enterprise System team and Sun's systems management team, but nothing beats my experience working with the most talented Identity Management team in the world. Oracle is inheriting THE BEST Identity products available and I wish them luck on their strategy and direction.
Although I'm very happy that this process has finally come to a close, I am sad to see Sun fading away. I believe the environment that Sun fostered was a once in a lifetime opportunity and I appreciate the experience and have tremendous gratitude for all that it offered me.
If you want to continue following my blog, I plan to continue to write on identity at www.smokingmonkey.org. Also, feel free to connect with me on LinkedIn.
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.
Here we are now. The European commission has officially blessed Oracle’s bid for Sun Microsystems. I do think Oracle is a great opportunity to rebound and move forward even though sadness and regrets are very much present today. Thanks to James Gosling for creating this great picture below (his blog post is here):
Thanks to my colleague Hua Cui, our OAuth implementation for OpenSSO is now upgraded to the latest 1.0a revision of the spec. There is no legacy support for (now deprecated) the 1.0 version (the version field hasn’t been changed in OAuth which, to me at least, does suggest deprecation of the previous release).
Since the signature mechanism in itself is not changed, there’s no update necessary to our Jersey OAuth signature library.
DSEE 7 launched in November and just after Christmas a couple of our Directory experts in the community at Sun took it for a test drive on the new F-20 PCIe flash drives at Sun. The results confirmed the internal testing we did in the improved performance in import times, the reduction in Directory footprint due to compression and the overall performance improvements for DSEE 7. This is critical for our customers because it will allow them to take advantage of growth in their business while bending the operational cost curve for their system. In some organizations, their operational budget is their biggest line-item so being able to meet growth targets while also addressing the time, cost and complexity of servicing the environment can release capital for investment in new product development.
The team that did this great work has agreed to share the results of their testing in a series of blog articles over the next week. The first article will be presented tomorrow by Brad Diggs, Principal Field Technologist. Here are just a few highlights from the results that Brad will share tomorrow on compression:
The storage footprint was reduced by as much as 66%.
We were able to cache greater than 50% more entries into the filesystem cache.
Compression almost completely negated average entry growth that is due to the natural addition of operational attributes and replication metadata over time.
The nsslapd-db-page-size could be smaller and more consistent with entry growth over time.
The other team members will be sharing insights that they learned during the testing so I encourage you to bookmark these blog's and take a look over the next couple of weeks. The team will be sharing not only the results but the lessons learned. One of the blog articles will discuss tuning to get better import times as well as how to set-up your own SLAMD environment to test your Directory infrastructure. Please bookmark the following blog locations to see the results:
Brad Diggs, Principal Field Technologist, here Ludo Poitou, OpenDS Community Manager, here Mark Craig, Directory Integration Team Manager, here Wajih Ahmed, Principal Field Technologist, here Nick Wooler, Directory Server Product Line Manager, here
As you look at your business goals for 2010 and are looking for ways to meet your growth goals while keeping your costs under control then take another look at Directory Server 7. Does your Directory Server provide you with the proven performance and continued innovation as Sun Directory Server Enterprise Edition 7?
Today, I imported all entries from this blog into my new WordPress blog at smokingmonkey.org. I'm using GoDaddy to host and installed my own instance of Wordpress. I plan to double-post content to both sites for the forseeable future. Figured it was time to have my own space to blog so I could be more irreverent then ever!
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¶meter2=value2¶meterN=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.
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:
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.
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.
requestTime - For example, env=requestTime%3D1248994000000.
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.
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:
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.
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.
requestTime - For example, env=requestTime%3D1248994000000.
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.
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.
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:
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.
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.
requestTime - For example, env=requestTime%3D1248994000000.
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.
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.
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:
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.
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.
requestTime - For example, env=requestTime%3D1248994000000.
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.
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.
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¶meter2=value2¶meterN=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.
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.
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_.
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.
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=changemeNOTE: 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.
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.
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.
Login to the OpenSSO console as administrator; by default, amadmin.
Click the Access Control tab.
Click / Top Level Realm.
Add the new host name as a value for the Realm/DNS Aliases attribute.
For example, new.example1.com.
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>
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.
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.
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/.
Search for <AttributeValuePair><Attribute name=”sunOrganizationAliases”/><Value>opensso</Value> and change opensso to opensso1.
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.
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
Save new.xml.
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.
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.
Change the deploy context on the OpenSSO web container to opensso1. Check the your web container's documentation for instructions.
Move OpenSSO-ConfigDir/opensso to OpenSSO-ConfigDir/opensso1. Be sure to backup this directory first.
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.
Change opensso in the AMConfig* file to opensso1.
Start the web container.
Log in to OpenSSO using the new URL (and host name) as amadmin.
Click the Access Control tab.
Click / Top Level Realm.
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.
Edit OpenSSO-ConfigDir/bootstrap by changing the new encoded URL back to the old encoded URL.
Import export.xml back into OpenSSO.
Change the deploy context on the OpenSSO web container back to opensso.
Move OpenSSO-ConfigDir/opensso1 to OpenSSO-ConfigDir/opensso.
Change opensso1 in the AMConfig* file (located in the user-home/.openssocfg directory) back to opensso.
Restart the web container.
Now enjoy Patrick Hernandez's one hit Born to Be Alive.
Many people reading my previous posts about our OpenID extension for OpenSSO asked me where is the OP (OpenID Provider) code in the OpenSSO repository. The answer is that there’s no code for it (right now) and the reason for this is that we thought deployers would likely develop their own OP with all the appropriate checks in place. But since I do get these requests and to complete the example I described in previous posts, Below is the source code for the simplest (i.e. dumbest) OP one can think of.
To refresh our memories after the holiday break, the role of the OP web application is to hand out the metadata related to the OpenID identifiers of (presumably known) users. That metadata (in the form of an html page with metadata placed in the <head> section) points to the location of the related OpenID server (for both versions 1 & 2).
In the present example, we will simply hand out that information to any appropriately formed URL (see this post). A real OP should probably verify that the OpenID identifier used corresponds to an existing user.
Please note that for the code below I chose to make my life easier and used the Jersey API to quickly create a simple web application. You can of course use servlets instead (or whatever) but REST is so easy with Jersey!
Apologies for the formatting but the string is way too long to fit in any way I tried. The key parts of that string are the two <link rel=…> elements which define the OpenID endpoints. Of course you’ll need to change those to match your deployment.
/**
* REST Web Service
*
* @author Hubert A. Le Van Gong <hubert.levangong at Sun.COM>
*/
@Path("/{id}")
public class OP {
@Context
private UriInfo context;
String standard_profile = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+ "<!DOCTYPE html PUBLIC\"-//W3C//DTD XHTML 1.0 Transitional//EN\"
+ \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\" >\n"
+"<html xmlns=\"http://www.w3.org/1999/xhtml\">\n"
+ " <head>\n"
+" <link rel=\"openid.server\" href=\"http://openid.example.com:49723/openid/service\"/>\n"
+" <link rel=\"openid2.provider\" href=\"http://openid.example.com:49723/openid/service\"/>\n"
+" <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/>\n"
+" <title>OpenSSO OpenID provider</title>\n"
+" <link rel=\"stylesheet\" type=\"text/css\" href=\"style.css\" />\n"
+" </head>\n"
+" <body>\n"
+" <div class=\"body\">\n"
+" <h2>This OpenID provider is based upon OpenID4Java & supports the following protocols</h2>\n"
+" <UL>\n"
+" <li>OpenID Authentication 2.0</li>\n"
+" <li>OpenID Authentication 1.1 (in compatibility mode)</li>\n"
+" <li>OpenID Attribute Exchange 1.0</li>\n"
+" <li>OpenID Simple Registration 1.0 and 1.1, draft 1</li>\n"
+" </UL>\n"
+" </div>\n"
+" <h2> To see the OpenID ID, view the source of this html page (usually achieved by right-clicking on the page)</h2>"
+" <div>\n"
+" </div>\n"
+" </body>\n"
+"</html>\n";
/** Creates a new instance of OP */
public OP() {
}
/**
* Retrieves representation of an instance of OP
* @return an instance of java.lang.String
*/
@GET
@Produces("text/html")
public String gethtml() {
return standard_profile;
}
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.
1. Open Sun DS Console or any LDAP browser and connect to backend DS configured for AM Server.
2. Browse to following DN : ou=default,ou=OrganizationConfig,ou=1.0,ou=iPlanetAMAuthService,ou=services,dc=sfbay,dc=sun,dc=com
3. Edit attribute sunkeyvalue attribute by modifying iplanet-am-auth-allowed-modules from UNIX to LDAP sunkeyvalue: iplanet-am-auth-allowed-modules=LDAP
In this episode we discuss the latest OpenSSO Express 9 launch and our new Fine-Grained Authorization (FGA) capabilities. We also explain why we chose a Resource Oriented Architecture when designing our FGA solution and did some therapy with Cote to help him deal with his exposure to a shaved, punk rock cat (we're hoping his health care covers the session).
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.
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.
Click the Federation tab.
Click the name of the appropriate hosted entity provider from the Entity Providers table.
Click the Advanced tab.
Click Relay State URL List (or scroll to the page's bottom).
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)
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.
For those that missed it, below is the webinar we recorded yesterday on OpenSSO's new Fine-Grained Entitlement Enforcement capabilities. Enjoy! You can also read the press release here.
I am among the team of 4 engineers who work on designing and implementing the entitlements service for OpenSSO project for a year. And we are happy to see that entitlements service is the key feature in OpenSSO Express 9 (see our press release).
Followings are the key things that we have done (I wrote about 80% of the SDK so it is ok to blame me if things are not working)
Improve scalability. We use indexes in LDAP server to locate policies for evaluation. This fast and heuristic approach helps us to eliminate most of unrelated policies and retrieve the related ones rapidly. Our latest test shows that we can handle over 1 million policies.
Improve performance. We use multi-threading, re-entrance read-write lock (Java concurrency package) and LDAP indexes to speed up policy evaluation. The performance has improved significantly as we benchmark it against the previous policy evaluation engine. We are in the process of tuning the caching system. And better results would be expected.
REST interfaces We have REST interfaces for policy evaluation and management. This means that non Java (such as PHP and Python) clients can make policy evaluation requests. State of art, Jersey is used for our REST implementation; and JSON is used too.
User friendly UI My co-worker has developed a nice set of entitlements services UI using icefaces
Currently, we are working with technical writers on documenting entitlement services. You should be able to see these document early next year when OpenSSO Express 9 is shipped.
Well, year 2009 is coming to an end. It has been a fun year working on entitlements service (among my other doings). Sleepless nights, long meetings, ranting and hanging my head on the keyboard (just kidding) are part of the fun . I hope that 2010 will be more exciting.
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.
Connect to the Configuration Data Store using an LDAPBROWSER client.
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.
Install an instance of OpenSSO in a test environment using the same value of am.encryption.pwd as the one above.
Connect to the Configuration Data Store on the temporary instance using an LDAPBROWSER client.
Navigate to to --> ou=Services --> ou= sunIdentityRepositoryService --> ou=1.0 --> ou=GlobalConfig --> ou=Default --> ou=users --> ou=amAdmin.
Select ou=amAdmin.
Its different attributes and associated values are displayed on the right. The value of sunKeyValue is displayed as userPassword=AQICGCVs587Ld67ZkiWlqauzaXQAqvx8g6YECMW/jzK62WNdhnBceHNEwg==.
Navigate to the Configuration Data Store on which you want to change the password and replace the old value with this new one.
Restart the web container.
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.
In previous posts, I mentioned we have implemented an OAuth signature library for Jersey (the JAX-RS reference implementation). This signature library sports client and server filters to insulate the application from most of the OAuth signature process (signing on the client side and verifying the signature on the server). Our main goal is to allow Jersey developers to adopt OAuth to secure their messages. Our initial need though, was for our OpenSSO project which now includes an OAuth Token Service.
In doing some testing on the OpenSSO use of OAuth, we noted there’s was a bug in the server verification code of an RSA signature. I’m happy to announce that the fix is in so you can now happily use RSA-SHA1 to secure OAuth messages (in OpenSSO or simply using Jersey). Similarly to HMAC-SHA1, we have created a comprehensive test for the RSA-SHA1, reusing the same test case used here. If you want to use the library, you should take a look at the test source code.
One thing to note is that all signature algorithm implementations (HMAC-SHA1, RSA-SHA1, more could be added.) use the same interface object class OAuthSignature method. The challenge with that is that those algorithm require different types of secrets (as reflected in the OAuth spec). It is especially true for key-based algorithms like RSA-SHA1 where the sign() method requires a different secret (the private key) than the verify() method (called by the server, using the client’s public key).
In our implementation both methods take an OAuthSecrets object in argument. In the case of a public/private key-based algorithm, this object is expected to contain the private key (or public key in the verification case) within the consumerSecret field. This is indicated in the library’s Javadoc.
On the client side, signing (with RSA-SHA1) a message is quite simple. All you need to sign your message is three elements: the request, the OAuth parameters and your public key. The code below shows how you’d do that with Jersey:
On the server side, we retrieve the parameters from the request and use the public key (obtained from the client’s X509 certificate). A short example would be:
params = new OAuthParameters();
params.readRequest(request);
secrets = new OAuthSecrets().consumerSecret(RSA_CERTIFICATE);
assertTrue(OAuthSignature.verify(request, params, secrets));
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.
There's a couple of nice technical articles available that demonstrate how to integrate EJBCA and OpenSSO. EJBCA is an enterprise class PKI Certificate Authority built on J2EE technology. It is a robust, high performance, platform independent, flexible, and component based CA to be used stand-alone or integrated in other J2EE applications. EJBCA provides users with digital certificates for strong authentication and digital signatures. OpenSSO uses these credentials to provide single sign-on and authorization. Check out the articles.
As we near the end of the year, Kuppinger Cole and Sun Microsystems will take an in-depth look at how you can externalize authorization using next-generation technology that scales! Analyst Felix Gaehtgens will review the market and provide insight into what's ahead, and Sun Chief Identity Strategist Daniel Raskin will share exciting news about how customers can use OpenSSO to implement a repeatable, scalable process for externalizing authorization.
Register Now for this free Webinar to learn more about:
* What's happening in the market regarding externalized authorization
* Key trends and priorities
* Actions you should think about for 2010 and beyond
* Fine-grained entitlement enforcement in OpenSSO Express 9
While other vendors offer fine-grained entitlement enforcement as a standalone solution, Sun's OpenSSO is the only solution to deliver access management, federation, secure Web services and now fine-grained entitlement enforcement — all in a single application.
Date: Wednesday, December 16, 2009 Time: 10:00 am PDT / 1:00 pm EDT / 19.00 CET (check my timezone) Duration: 1 hour Speaker: Kuppinger Cole Analyst Felix Gaehtgens and Sun Chief Identity Strategist Daniel Raskin
DSEE 7 launched in November and just after Christmas a couple of our Directory experts in the community at Sun took it for a test drive on the new 
Listen Now 
. I hope that 2010 will be more exciting.
