OK, it's not technically a rip-off but that's all I could come up with in the time allotted.
The team of OpenSSO engineers have been working on a new administration console. The plan is to release a beta version of the new console with OpenSSO Express Build 8. Although the trees that contribute to the nightly build and the Express 8 build have not yet been consolidated, portions of the new beta console are available for your perusal in the nightly build. Things will undoubtedly change before the actual release; the following information is so you can take a look at the direction we are going.
This new OpenSSO administration console is in beta and should only be used for test environments. Continue to use the standard OpenSSO administration console for real-time deployments.
After deploying opensso.war to a web container, login to OpenSSO as the administrator and enter protocol://machine.domain:port/deploy-uri/admin in the Location Bar of a browser to display the new console interface.
The Entitlements, Federation and Web Service Security tabs comprise the bulk of features currently in this new console. Accommodations have been made for these features by providing inline help displayed on the console screen. Additional documentation will be available after the beta release.
Working With the Entitlements Service
The Entitlements tab contains the new work flows for ease-of-use when creating new, and managing existing, policies for the new Entitlements Service. These features are only available in the beta administration console. You must choose the framework with which you will be creating policies for your resources. The options are the Policy Service using the standard administration console and the Entitlements Service using the beta administration console. Once the choice is made (by creating and saving a policy using one or the other), only that service (Entitlements or Policy) will be enabled. Migration of policies from previous versions of OpenSSO is not supported.
Using the Federation Work Flows
The Federation tab contains the new work flows for ease-of-use when creating and registering entity providers for the Federation Service using the SAMLv2 protocol. These work flows are available in either the standard or beta administration console. If you create SAMLv2 entity providers using the work flows in the beta administration console, you manage the configurations using the standard administration console.
Using the Web Services Security Work Flows
The Web Service Security tab contains the new work flows for ease-of-use in creating profiles to work with the Web Service Security framework. These work flows are available only in the beta administration console although profiles can also be created by manually configuring attributes using the standard administration console. You can create profiles in the beta console and manage them in the standard console.
The intent with the beta administration console is to hide realms. If no realms are configured using the standard console, the applicable interface to switch realms will not be visible in the beta console, nor anything about referrals. If you create a realm using the standard console, realm and referral menu items are visible.
Now enjoy the greatly, soulful Laura Lee and her 1972 hit, Rip-Off.
I know there are people out there who have been wondering where my blog entries have been for the last two and a half months - and to both of you I say: I've been assiduously (thanks for the word, Alan) working on two deployment books for release with Sun OpenSSO Enterprise 8.0. Here are links to the PDFs - test them out and let me know what you think.
But all that work has made me drowsy so I'm taking two weeks off now. In the meantime, enjoy As We Stumble Along featuring Robert Martin as Man in Chair and Beth Leavel as The Drowsy Chaperone. You gotta love a song that rhymes stumble with...parumble?
Installing and configuring Directory Server as a user data store.
Installing J2EE and web policy agents on protected resources.
Installing and configuring OpenSSO instances to run as a non-root user.
Configuring load balancers for session failover and high performance.
Configuring the deployment for system failover, ensuring that when one instance of OpenSSO Enterprise goes down, requests are redirected to the second instance.
Configuring components (including OpenSSO and Directory Server, the Distributed Authentication User Interface, and policy agents) as redundant to achieve high availability.
Configuring for Secure Sockets Layer (SSL) communications to the OpenSSO load balancer, to the Distributed Authentication User Interface load balancer, and to the Directory Server load balancer.
So check it out. You can also see the complete set of Early Access documentation for OpenSSO Enterprise 8.0. Now is the time to air your thoughts.
Thanks to Sun engineer Anant for his work on the book. Because of it, this book is an invaluable tool for understanding and keystroking an OpenSSO deployment.
And whether you are ready or not, Bucks Fizz certainly is. Are You Ready is the title song of their second album. Not sure if it's Jay or Cheryl wearing the diaper but it's quite an 80s sight!
It's in the mountains of Colorado and, according to the web site, the SSO Summit is the only conference to arm you with case-studies, war stories, success stories and shared expertise. Click here for more information. But come back to dance with The Shamen as they Move Any Mountain.
Get it? Summit. Mountain.
I'm going, btw.
Fedlet is the catchy name given to fedlet.war. The WAR is a very small archive of a few JARs, a keystore, and metadata (all stored in flat files) that can be embedded into a service provider's Java EE web application to allow for single sign-on (SSO) between an identity provider instance of OpenSSO and the service provider application - WITHOUT installing OpenSSO on the service provider side. The service provider simply downloads the Fedlet, modifies their application to include the Fedlet JARs and, re-archives and redeploys the modified application. The service provider is now able to accept an HTTP POST (that contains a SAML assertion) from the identity provider and retrieve included user attributes to accomplish SSO. (Currently, the Fedlet only supports the HTTP POST Profile.) The flowchart below illustrates how the instance of OpenSSO, configured as the identity provider, determines the user attributes to include in the SAML assertion sent to the service provider.
The Fedlet currently supports identity provider-initiated SSO (push) and service provider-initiated SSO (pull).
Identity Provider-initiated SSO
In identity provider-initiated SSO, the user is authenticated to the identity provider and, thus, able to successfully access a remote service provider. In other words, the user accesses an identity provider (a telco), and clicks on a specialized link to a service provider enabled with the Fedlet (ringtone retailer). The link triggers the creation of a SAML assertion which carries user authentication information to the service provider, allowing the user to gain access via back-end SSO. The following figure illustrates this.
More specific flow information is mapped out in the following diagram.
Service Provider-initiated SSO
In service provider-initiated SSO, the user attempts to access a service provider without a current session and is redirected to the identity provider for authentication. Following successful authentication, the identity provider posts a SAML assertion to the service provider and the user is allowed access. The following figure illustrates this scenario.
More specific flow information is mapped out in the following diagram.
There are two ways to create the Fedlet. You can use the OpenSSO Common Tasks wizard, or you can download the fedlet-unconfigured.zip file and configure it yourself. In this entry, we do the former. When completed the Fedlet contains a JavaServer Pages (JSP) file that we will use to test the configuration.
Creating a Fedlet with the Common Tasks Wizard
If OpenSSO is deployed as the identity provider, the Fedlet.war can be created through a work flow. The identity provider follows the configurations steps on the Common Tasks page of the console to create the Fedlet.zip bundle (that will consist of the Fedlet.war and a README file with instructions on deploying the Fedlet). The Fedlet.war would then be deployed and configured by the service provider.
Before beginning Fedlet creation using the Common Tasks wizard, you must create entity providers and a circle of trust on both the identity provider (IDP) and service provider (SP) instances of OpenSSO. Thus, after using the wizard, the Fedlet will contain pre-configured provider metadata and circle of trust information. See Common Tasks and Common People for the procedure to create the providers and circle of trust. After this is done, follow the steps below to create and test the Fedlet.
Login to the OpenSSO Console on the IDP side.
Navigate through the Access Control - > top-level realm -> Subjects tabs to access the profile of the demo, a default user created during OpenSSO deployment.
Add values to the Email and Employee Number attributes of the demo user profile.
Click Save and navigate back to the Common Tasks tab.
Click Create Fedlet.
Add the following URL to the Name and Destination URL attributes: http://fqdn-of-SP-machine:port/fedlet
On the same screen, under Attribute Mapping, add the following mappings:
employeenumber | employeenumber mail | mail
When the Fedlet has been created, you will see the following message:
Your Fedlet.zip file has been created.
Your file has been saved to your opensso folder:
Send the created Fedlet.zip to the SP machine.
Unzip Fedlet.zip on the SP machine.
Login to your web container and deploy the fedlet.war.
Go to http://fqdn-of-SP-machine:port/fedlet/index.jsp.
The following screen is displayed.
Click the link to create the /fedlet configuration directory.
After the directory is created, the following screen is displayed.
Click Run Fedlet (SP) Initiated Single Sign-on to validate the first Fedlet setup. You will be redirected to the IDP login screen.
Login to the IDP as user demo with password changeit. demo will authenticate first with the IDP and then with the SP using SSO. (Watch how the URL changes in your browser.) When the interaction is complete, the screen displayed shows the mapped attributes and links to view the SAMLv2 Response, the Assertion, and the Authentication Statement (Subject) communications used.
Go back to http://fqdn-of-SP-machine:port/fedlet/index.jsp and click Run Identity Provider Initiated Single Sign-on to validate the second Fedlet setup. You will be redirected to login to the IDP console. Use demo again. When the interaction is complete, the screen displayed shows the mapped attributes and links to view the SAMLv2 Response, the Assertion, and the Authentication Statement (Subject) communications used.
Coming next is how to use the fedlet-unconfigured.zip with your own application. In the meantime, the title of this entry made me think of the kid's television program, Winky Dink. Here's the opening credits from the 50s version I don't remember mashed with the theme song from the 60s version I do remember. I put this together special - for those who remember the Winkster.