Bruno Bonfils, aka asyd, longtime denizen of #opensso, has put together a VMware instance with OpenSSO and EJBCA. In Bruno's words:

The image was made to demonstrate an application protected by opensso. The application is divided in three parts, the first one is available for everyone (non authenticated users). The second part, the secure area, is available only for users authenticated in OpenSSO, and members of group employee. And finally, only users authenticated by certificates and member of group employee can access to the very secure area.

Watch for a series of articles at Sun Developer Network (feed) describing the integration in more depth; in the meantime, you can go download the instance and have a play - instructions are included...

When you create courses, you sometimes do crazy things like installing multiple GlassFish domain administration servers (DAS) in a single host.

When you install GlassFish, it gives you default port numbers of of 4848 (for administration), 8080 (for the HTTP listener), and 8181 (for the HTTPS listener). But what do you do if you want to change them?

I got a few ideas googling "asadmin port number" and the like but couldn't really find a good example. So, I figured out how you do it and thought I would post an example in case anyone finds themselves in the same predicament as I did today.

Here are some examples:

1. To change the HTTP port to 10080:
   
   asadmin set server.http-service.http-listener.http-listener-1.port=10080
   
   
2. To change the HTTPS port to 10443:
   
   asadmin set server.http-service.http-listener.http-listener-2.port=10443
   
   
3. To change the administration server port to 14848:
   
   asadmin set server.http-service.http-listener.admin-listener.port=14848
   
   

It's handy to know you can grep for server properties as follows:

asadmin get server | grep listener

shows all the properties with the text "listener" in them.

In GlassFish v3 Prelude, you can set port numbers for administration and the HTTP listener in the installer - but not for the HTTPS listener. You might find yourself needing to explicitly specify the administration port in your asadmin command. For example:

asadmin set --port 14848 server.http-service.http-listener.http-listener-2.port=10443

Hope this is helpful to someone.

If you have been reading my blogs on OpenSSO lately, there is a red line through all of them.
OpenSSO is breaking down technology walls, allowing connectivity from OpenSSO with a larger growing set of back-end technologies.

I just discussed OpenSSO's ability in federating with Shibboleth via SAML1 and via SAML2 (something that seemed impossible before).

As we are speaking, the next  step is in the making, allowing OpenSSO to install a fedlet on a .NET environment, allowing that .NET environment to take the role of a Service Provider(SP), and consume identities authenticated by OpenSSO in the IDP Role.

Please have a look at the following Blog entry by Rajeev Angal about the .NET Fedlet (prototype)
Keep watching the evolutions on opensso.org for this feature to appear.

I mentioned part 1 of 'Protecting Applications With Jave EE Policy Agents' at the beginning of this month; this week sees part 2, with Hua Cui joining Sean and Marina to give more detail on how to deploy OpenSSO's Java EE Policy Agents for single sign-on within a single DNS domain, configuring several sample Java EE Web applications and having OpenSSO provide single sign-on between them.

And, with that, I'm taking a break until 2009. It's been an amazing year for OpenSSO - we shipped our first Express release in July, and our first fully supported commercial release, OpenSSO Enterprise 8.0, in November. We've seen integrations with systems from ActivIdentity 4TRESS to YubiKey (YubiKey was the closest I could get to 'Z' ) and deployments from ACA/Telenet to Yota. Dang it! Isn't there anything OpenSSO-related that begins with 'Z'?

Meanwhile, on the community side, the number of registered project members has risen from about 550 at the start of 2008 to over 900 today, while the monthly traffic on the OpenSSO Users mailing list has gone up from around 200 messages a month to nearly a thousand. Even the IRC channel is buzzing now, with contributors from Minsk to Shanghai talking OpenSSO around the clock. If you haven't yet dipped your toes in the OpenSSO water, perhaps now's the time to get started?

Using OpenSSO to connect to Shibboleth 2 IDP's has become very easy with the latest changes in OpenSSO.  
These are the steps to accomplish this :

1. Use the latest nightly OpenSSO build (or the next Stable build that will be released), you will need many fixes from the last weeks, therefore the last OpenSSO Express build is too old...
2. Create a Hosted IdP Configuration in OpenSSO console (if you want to use it in production, make sure to have your credentials in the keystore, for proof-of-concept scenarios the keystore contains one test key)
3. Grab the newly created OpenSSO IdP metadata XML (you can use either ssoadm.jsp export entity command or access directly
   /opensso/saml2/jsp/exportmetadata.jsp?entityid=) and reference it in the SP configuration.
4. Edit the Shibboleth SP metadata (/Shibboleth.sso/Metadata), and remove all the XML digital signature AND the nodes.
5. Import the modified SP metadata to OpenSSO (Via ssoadm.jsp, the import CLI or through the OpenSSO console)
6. In the OpenSSO console, add the IdP and SP metadata to one Circle of Trust profile
7. Use the OpenSSO console to edit the IdP metadata, and add attributes.

All the released attributes must use the URI-style attrname-format (Shibboleth won't accept unspecified attribute nameformat), so use
the following syntax : urn:oasis:names:tc:SAML:2.0:attrname-format:uri|=

That's it : from now on you can federate identities with the Shibboleth 2 IDP.

The following was posted in the opensso users mailinglist, that a lot of people found very interesting to say the least !

Chris Phillips (chris.phillips@queensu.ca) wrote an article on how OpenSSO Enterprise can be configured as an Shibboleth 1.3 IDP.
The article can be found at : https://wiki.queensu.ca/display/heidm/HowTo-Building+a+Shib+IdP+1.3+with+Sun+Access+Manager+7+for+SSO

Academic World : Here comes OpenSSO !
Technorati Tags: opensso shibboleth

こんにちは。
皆様は、アプリケーションのアクセス制御はどこで行なっていますか？

シングルサインオン製品が導入されている場合には、シングルサインオン製品上で行なっている場合もあるでしょう。また、業務アプリケーションは独自のアクセス制御の仕組みをもっていることも多いので、業務アプリケーション側で行なっている場合もあるでしゃう。場合によっては、自社開発のアプリケーションで行なっている場合もあるかと思います。

つまり、企業内にはアクセス制御を行なう場所やアクセス制御を行なうための情報が分散している言えます。

非効率だな？とか、監査やコンプライアンス上問題が発生するのでは？？とかお考えになる方もいるのではないでしょか。
そうですね。分散管理には、効率性の欠如や、監査・コンプライアンス上の問題が付きまといます。

そんな、企業内に散らばっているアクセス制御を行なうための情報を一元的に管理して、アクセス制御の処理も集中的に行なうと、効率的でかつコンプライアンス・内部統制という観点からもよいのではないかということから考えだされたのが最近ID管理分野でよく話題にのぼるようになってきたエンタイトルメントマネジメントです。

OpenSSO EnterpriseのプロダクトマネージャのDanielが、Sunのエンタイトルメントマネジメントへの取り組みをブログに書いていますので紹介します。

1. We are in the process of expanding OpenSSO to handle Fine Grained Authorization / Entitlement Management out-of the box! We will NOT sell you another thing that you need to deploy in to your datacenter.
   
   我々は、Fine Grained Authorization（より細かいレベルの認可）/エンタイトルメントマネジメントの機能をOpenSSOの製品機能として取りこもうとしています。
   
2. You will see this in OpenSSO Express by late Spring / Early Summer! Yep. This one is in the works and it's going to be very cool. We have some slick ideas and this is going to be our next "fedlet."
   
   来年の遅い春か早い夏（たぶん6、7月かな？）には、OpenSSO Express の中にその機能が入ってくると思います。今、ちょうど開発している最中ですが、とってもクールです。ちょっといかしたアイデアもあるんです。次のfedletという感じです。
   
3. It will be all be open source! You heard that right. Everything we do will be available via the opensso community and free to use. If you are interested in contributing let us know.
   
   もちろん、オープンソースです。驚いたでしょう。我々が実装していく成果は、opensso communityを通して利用可能です、自由にお使い頂けます。もし貢献していただくことに興味がおありでしたらぜひお知らせください。

Sun will be the ONLY provider to offer a single solution that not only does access controls, federation and secure web services, but also entitlement management. Stay tuned for more to come!!!!

Sun は、アクセスコントロール、フェデレーション、セキュアWebサービスの3つの機能だけでなく、エンタイトルマネジメントの機能も1つのソリューションで提供する唯一の会社です。今後もご注目ください
Entitlements Pyramid Scheme - The Smoking Monkey

では、今日はこんなところで。

_kimimasa

Gartner recently released the Nov 2008 report on Web Access Management and Sun is now listed in the leader's quadrant (see image). This is good news, both as a recognition of our efforts and also because some customers use the Magic Quadrant to evaluate the viability of some vendors. Sun's product in this space is OpenSSO 8 Enterprise - the commercial distribution of OpenSSO. The product version runs on GFv2 but it can also be used on GFv3 prelude; just need this small workaround :-) Of course it will be fixed in the final v3.

There's been quite a bit of activity around OpenSSO; other recent news include connectivity to SalesForce, and to SugarCRM, Using simpleSAMLphp, and even a .Net prototype. If you want to track all OpenSSO news, you may want to check SuperPat (Pat Patterson) and Smoking Monkey (Daniel Raskin).

From Japan, news that Nomura Research Institute (NRI), a consulting and IT solution services company spun off from Nomura Securities, are offering support and services for OpenSSO [Japanese press release] [Google translation to English], including OpenID for cross-enterprise authentication.

As well as being a big endorsement for OpenSSO, this event marks its graduation as an open source project - it's definitely no longer 'just a Sun thing'.

Welcome, NRI! We look forward to your contributions to OpenSSO!

Ever seen a customer ask the following ?

We have a custom made Web-SSO solution, and would like to migrate to OpenSSO.  How can we do this in an application by application fashion, by having the 2 solutions coexist during the migration phase ?The easy answer would be : use federation.  But the lack of federation capabilities may very well be the reason why they want to move to OpenSSO, or the customer may not want to spend money by adding federation functionality to a product that is about to be phased out.

So how do you do it ?
There are a couple of scenario’s to do this, but one scenario may be the easiest :

1. Deploy OpenSSO
   


2. Protect OpenSSO as you would protect any web application with the old SSO solution. (this can be done by an agent, proxy, or any other way it was done in the past)
   
   
3. In OpenSSO, create and deploy a zero-page custom authentication module. This is a very simple authentication class getting the userid from the HTTP header, allowing  the userID to be used later by OpenSSO when starting the session. At this point, there is no need to verify the password, as that was already done inside the old SSO environment.
   

As a result the following is true :

• Applications still connected to the old SSO environment will be authenticated the old-fashioned way.
  
  
  If however the end-user moves to an already migrated application, that application will request the identity from OpenSSO.  As there will be no session inside OpenSSO yet, OpenSSO will start it's own authentication via the above described zero-page fashion, (thus by receiving the userid from the old SSO solution - received when OpenSSO redirects forward and back to the old SSO solution when handling its own protection)
• In the event a user starts with an already migrated application, he/she will be redirected to OpenSSO for authentication. As OpenSSO is protected by the old SSO solution, authentication will be required inside the old SSO solution meaning that the user is redirected once again to the old SSO solution. Once authenticated there, the user will be redirected back to OpenSSO, the userid will be used for the session (via f.e. the HTTP header), and the application will be given the correct userid by OpenSSO. The end-user can now freely move to application not migrated yet, as the session already exists in the old SSO solution.
  

Therefore, the experience for the end-user is full SSO between migrated and not-migrated applications.

When the migration is completed, OpenSSO can be configured again not to be protected by the old SSO solution, and the new authentication modules can be activated replacing the zero-page authentication module.
That way, all migrated applications will be served by OpenSSO and the old SSO solution can be removed.

Our latest Adoption Story comes from Belgium thanks to SuperPat. Telenet (home, wikipedia) is the largest supplier of broadband cable services in Belgium. They needed fine-grained access control for internal applications and ACA-IT provided it through OpenSSO. See Questionnaire for full details.

For more adoption stories, check our Informal Stories. We are always looking for stories showcasing production use as these are critical to the growth of our community. If you are a happy user please consider sharing your story by sending us mail to stories at sun dot com.

It's been a while since the last tab sweep - lots of news since then, such as the OpenSSO Enterprise 8.0 release, that's kept me busy both here on the blog and 'in real life' (if there is such a thing any more!). Anyway, here are some of the titbits I've been saving for a tab sweep blog post:

• I posted another OpenSSO adoption story to the Stories blog this morning: ACA IT-Solutions deploys OpenSSO at Telenet for fine-grained access control. You might remember I blogged about Telenet a little while ago, well, when we started covering OpenSSO on the Stories blog, Serge Craeghs of ACA IT-Solutions kindly completed the questionnaire for the Telenet deployment, with all sorts of juicy details - read all about it.
• Another nifty feature of MarkMail - project-based homepages. Just go to http://opensso.markmail.org/ and you can search and browse just the OpenSSO mailing lists. Very cool!
• Bert van Beeck writes about using SAML 1.x or SAML 2.0 to authenticate SharePoint users, with OpenSSO acting as a bridge between the Belgian Federal Authentication Service - FAS (a SAML 1.1 identity provider) and Microsoft SharePoint (which can speak WS-Federation, but not plain SAML 1.1).
• On The Open Road, David Goldsmith explains how to work around issues in GlassFish V3 Prelude's cookie handling to allow OpenSSO to work correctly, with a nod to Dennis' diagnosis of the problem.
• Although the Fedlet has been available for Java EE platforms for some time now, it's always been our intention to support .Net also, so it's great to see Rajeev Angal putting together a .Net Fedlet prototype. Give it a try and let Rajeev know how it goes.
• Rajeev strikes again, alongside Marina Sum, with a Sun Developer Network article on Federated Single Sign-On for Salesforce in OpenSSO. It's amazing how easy these integrations are now that SAML has become so widespread. There might just be something to these 'standards' we keep hearing about
• Over at Core Security Patterns, Ramesh Nagappan tantalizes us with a glimpse of a solution composed of Match-to-SmartCard PKI and Biometric authentication - starring OpenSSO in "multi-factor authentication based Web SSO that uses on-card credentials (PIN + PKI + Biometrics) using PIV card." More details, please, Ramesh!
• Finally, John Willis' CloudDroplets #20 podcast covers the 'OpenSSO in the Clouds' presentation I gave this week at the AWSome Atlanta Meetup. Thanks again for the invitation to speak, John, I had a blast!

Well - that wraps things up for this week. Don't forget to vote for OpenSSO in the SOA World Readers' Choice Awards!!!

• Google Trends: opensso
  Nice - you can see search search traffic for OpenSSO increasing over the past year or so.
  (tags: opensso google trends)

Telenet is a leading supplier for media and telecom services in Belgium, providing broadband Internet, multi-media, fixed-line and mobile telephony and digital TV services to residential and professional clients in Flanders and Brussels. When they needed fine-grained control of employee access to internal applications, they turned to ACA IT-Solutions, probably the largest and most successful independent Java solution provider in Benelux.

ACA, having long experience with Sun Access Manager, selected OpenSSO to provide fine-grained access control, using it as a central policy administration point (PAP) and developing a distributed policy decision point (PDP) to allow massive scaling and fault tolerance.

Read the full questionnaire to learn exactly why ACA selected OpenSSO for this critical role, and how "being able to dive into the source code often proved to be very useful for documentation's sake or making very subtle customisations." As Serge Craeghs of ACA writes, "Hey, who doesn't want to be in control? :)". Who indeed?

こんにちは。
今日はSunのオープンソースのお話です。
OpenSSO はオープンソースのシングルサインオン製品です。Access Managerとしてたくさんの企業で実績のある製品をオープンソース化したもので、既に多くの実績をもっています。そして、フェデレーションやウェブサービスの機能も1つの製品で実現できるのが大きな特徴です。
また、最近日本語のページも登場しました。

OpenSSO 日本語ページにリダイレクトされるようになりました。- Hanaki's weblog

そんなOpenSSOの構築やコンサルティングを提供している会社を紹介します。
1社は、ご説明する必要もないと思いますが、オープンソースに非常に力を入れているNRIさん

• シングルサインオンを低コストで実現する～オープンソース・ソフトウェア 「OpenSSO」のサポートを開始～

もう1社は、会社名にオープンソースと入っている、オープンソース・ソリューション・テクノロジーさん

• OpenSSO：シングル・サイン・オン ソリューション - Open Source Solution Technology Corporation

このようにオープンソースを生業としていらっしゃる会社さんがソリューションとして提供されるということは、OpenSSOが優れた製品であるということ証明でもあると思います。

OpenSSOに関する情報は、OpenSSO - kimimasa - wikis.sun.com　にまとめていますのでこちらもご参照下さい。

_kimimasa

SOAWorld have extended the closing date for votes in their Readers' Choice Awards until the end of the year - Dec 31st. And IBM DataPower has pulled ahead of Sun Access Manager/OpenSSO, by 540 votes to 345.

So... We NEED your vote... If you haven't voted already, go now and vote for OpenSSO in the Best Security Solution category. You could also vote for GlassFish in Best App Server and NetBeans in Best IDE, but I'm calling for votes for OpenSSO!!!

PLEASE - go vote now. And tell your friends. Vote, vote, vote!!!

Please follow the below steps to overcome the common issue of infinite redirection happening between OpenSSO server and the Client (agents, dist auth). One common cause is the cookie encode/decode happening on either the server or client or both.

Case 1) If OpenSSO 8.0 (deployed on any container) and J2EE Agent 3.0 or openssoclientsdk.jar is being used, by the below property should be set to "true".

com.iplanet.am.cookie.c66Encode = true

You can reach the above property by logging into the Opensso Console and traversing the below path:

(Configuration => Servers and Sites => Default Server Settings => Advanced)

By default the value for the above property is set as "false".

Case 2) If  the container used is Sun Java System Web Server 7.0 (both server/client), below steps need to be done:

1. The admin should be informed to disable the container level cookie encoding. 

          Log into the SJS Web Server 7.0 Admin console and follow the below path

          (Configurations=> [server instance] => Java => Servlet Container => Encode Cookies)

          By default the property is enabled.

• Also make sure that the below property is set to "false" in OpenSSO server.

          com.iplanet.am.cookie.encode =  false.

          You can reach the above property by logging into the Opensso Console and traversing the below path:

         (Configuration => Servers and Sites => Server Name => Security =>Encode Cookie Value)

         By default the value for the above property is set as "false".

Case 3) There will not be any issue with non-Sun Java System Web Server 7.0 client with non-Sun Java System Web Server 7.0 as long as the below property is set to "false"

com.iplanet.am.cookie.encode =  false

Case 4) If a configuration involves Sun Java System Web Server 7.0 (server or/and client) and for some reason the Sun Java System Web Server 7.0 container level cookie encoding cannot be disabled, then the property settings need to be looked into case by case.

As President-elect Obama announced his Energy Team yesterday, I was excited for two reasons.  One, Steven Chu is a Californian from Lawrence Berkeley National Laboratory and it is nice to see local citizens playing National and Global roles improving our environment.  Two, I am proud to work at Sun because a large number of the energy innovators like Argonne Laboratory, which is also a part of the Department of Energy, are using Sun's Software to provide the backbone of innovation within these organizations.  

Argonne Laboratory uses Directory Server Enterprise Edition to power their collaboration infrastructure.  They also use MySQL, JavaES, OpenSSO Enterprise and Virtualization (e.g. xVM Server) to power their innovation.  You can see a great video with David Salbego, Director of IT Infrastructure at Argonne National Labs regarding his experience and business benefits resulting from Sun solutions. 

BC Hydro also used OpenSSO Enterprise and Directory Server to reduce cost of providing a web portal for their customers to get interact with their organization.  They reduced the use of paper and conserved resources for our environment.  You can read about the solution here.

• Opensso Home - MarkMail
  OpenSSO project-based homepage for MarkMail. MarkMail is a REALLY nice way to search archives of public mailing lists.
  (tags: opensso markmail)

Prerequisites:

Glassfish V2 UR2

opensso_enterprise_80.zip

appserver_v9_agent_3.zip

Make sure to have a FQDN entry in <drive>:\windows\system32\drivers\etc\hosts. For example:

127.0.0.1 localhost my.test.domain.com

Have a password file named "passwordfile"(no file extension) with content "adminadmin" in some folder to point later.

Cleanup if already opensso installed and configured (just to startup from the scratch):

1. Remove/rename the folder "opensso" present in the user documents

(For example c:\document and settings\<username>\opensso)

2. Undeploy all the web/enterprise applications present in glassfish domains

3. Recreate domains in glassfish

• asadmin delete-domain domain1

• asadmin delete-domain domain2

• asadmin create-domain domain1 --user admin --adminport 4848 --instanceport 8080 domain1

• asadmin create-domain domain2 --user admin --adminport 4849 --instanceport 8081 domain2

4. Re extract the j2ee-agent (appserver_v9_agent_3.zip) in some folder

Installing opensso:

1. Modify the jvm option "-client" to "-server" and "-Xmx512m" to "-Xmx1024m" in the domain1's domain.xml (present in .../domain1/config file)

2. Start domain domain1. asadmin start-domain domain1

3. Access the admin console http://my.test.domain.com:4848. Login with admin username.

4. In the applications -> web applications node, deploy the opensso.war (...\opensso\deployable-war\opensso.war)

5. Launch the opensso application

6. Enter the username and password as "amadmin" and "adminadmin" respectively

7. Choose either of the two options (default configuration/new configuration) and complete the wizard with passwords provided for the different profiles. Now you are logged in after this configuration.

8. Select "access control" tab

9. Click /(Top Level Realm)

10. Go to Agents tab

11. Select J2EE sub tab

12. In the agent section click "new" button

13. Enter the name as "demoagent" and the password as "adminadmin" same to confirm password

14. Choose centralized configuration

15. Give the server url as http://my.test.domain.com:8080/opensso

16. Give the agent url as http://my.test.domain.com:8081/agentapp

17. Click on create button

18. Now click on the demoagent link.

19. Go to the General section, remove the "All" option and Give the Map value as "SSO_ONLY" with Map key left blank

20. Choose Agent debug level as "message"

Save the configuration

Installing Agent:

1. Goto the ...\j2ee_agents\appserver_v9_agent\bin directory

2. Type agentadmin --install. Read and agree instructions.

3. Subsequent prompts will ask for:

   1. Application Server Config Directory : <drive>:\Program Files\glassfish-v3- prelude\glassfish\domains\domain2\config

   2. Application Server Instance name : server

   3. OpenSSO server URL : http://my.test.domain.com:8080/opensso/

   4. Agent URL : http://my.test.domain.com:8081/agentapp

   5. Agent Profile name : demoagent

   6. Agent Profile Password file name : <dir path to file>\passwordfile

Note: In step '5', giving the profile name same as what we named in the opensso configuration

4. Review inputs and continue (input 1 to continue)

5. Installation of the agent is over.

6. Start the domain2. (No need to change any JVM options in domain2)

   asadmin start-domain domain2

7. Access the admin console http://my.test.domain.com:4849 and Login with admin user

8. In the "Enterprise applications" node, deploy the sample <drive>:\j2ee_agents\appserver_v9_agent\sampleapp\dist\agentsample.ear file.

9. Launch and verify if the application is working. (should work)

 

 

10. In the "Web applications" node, deploy the <drive>:\j2ee_agents\appserver_v9_agent\etc\agentapp.war. Try launching it. (will show the opensso folder structure)

 

11. Now try deploying and launching the mini-agentsample.war in the same "Web applications" node.

 

 

I came across a question regarding Sharepoint and SAML1.1.
A partner wanted to connect Microsoft Sharepoint with a SAML 1.1 Identity Provider (in this case the Belgian Federal Authentication Service - FAS).
The main problem is that Sharepoint does not speak SAML 1.1, nor does the Windows platform it is running on.

The solution via Sun's OpenSSO is simple as it supports loads of federation protocols !

1. First setup SAML 1 single sign-on between the SAML 1 IDP and OpenSSO as SAML1 SP


2. Then setup WS-Federation SSO between OpenSSO as an IDP and Microsoft Sharepoint as a Service Provider (SP)


3. Initiate SAML 1 SSO from the SAML 1 IDP with final redirect URL set to the  OpenSSO WS-Federation SSO initialization point  (for example http://://WSFederationServlet/metaAlias/?goto= )


4. In this case, SAML 1 IDP will start an IDP initiated SSO and post the Assertion to the OpenSSO  server instance


5. The OpenSSO server will then process the SAML1 protocol accordingly, and  redirect to WS-Federation SSO initiation URL


6. After completion, OpenSSO will then  start WS-Federation protocol and send the assertion to Microsoft Sharepoint to complete  WS-Federation protocol.
   

One thing to note - Sharepoint will need an 'SP' instance of AD-FS to communicate with OpenSSO as Sharepoint itself does not speak WS-Federation.

So - the protocol connection would look like :
SAML 1 IdP -- SAML1 --> OpenSSO -- WS-Fed  --> AD-FS --> Sharepoint 

Thank you Pat Patterson and Qingwen Cheng for helping me solve the question.

A similar use-case using SAML2 in stead of SAML1 is even more easy, thanks to OpenSSO's multi-federation Protocol Hub.

If you are a Facebook user that has received some crazy emails recently from "friends" with enticing subject lines to click on a video or picture should think twice before clicking the link.  The Koobface virus has rared it's ugly head again and for some in the eweek article posted here have had to throw out their PC's because of being infected.  Facebook has been great about identifying scams and exploits and maintains this page for users to get information about their security.  

In the interest of spreading the word and propagating good usage of the internet:

Here are some ways to be smart and aware on Facebook:

• If a link or message seems weird, don't click on it. This is true of all spam—whether a chain letter, an ad, or a phishing scam. If it seems weird for an old friend to write on your Wall and post a link, that friend may have gotten phished. Let the person know, and don't click on links you don't trust.


• Be aware of where you enter your password. Just because a page on the Internet looks like Facebook, it doesn't mean it is. Learn to tell the difference between a good link and a bad one.


• Report any spam or abuse you see on discussion boards and Walls. Those report links are there for a reason. The sooner we find spam, the sooner we can remove it and eliminate spammers from the site.


• Don't use the same password on Facebook that you use in other places on the web. If you do this, phishers or hackers who gain access to one of your accounts will easily be able to access your others too. You might find yourself locked out of your email and even your bank account.
  
  
• Never share your password with anyone. Don't do it. Facebook will never ask for your password through any form of communication. If someone pretending to be a Facebook employee asks you for it, don't give it out, and report the person immediately.
  

• Don't click on links or open attachments in suspicious emails. Fake emails can be very convincing, and hackers can spoof the "From:" address so the email looks like it's from Facebook. If the email looks weird, don't trust it, and delete it from your inbox.
  
  
• Add a security question. If your account ever does get stolen, you might need this to prove your identity to Facebook. If you haven't already done so, you can add a security question from the "Account Settings" page.

Also, if you are interested in avoiding scams during the holiday season here is a helpful site from CNET.  The site can be viewed here.

I've been building some training for OpenSSO Enterprise 8.0, and I want to use GlassFish v3 Prelude Release as my OpenSSO web container for this training.

So I pulled down the GlassFish release, installed it, deployed OpenSSO, started up the OpenSSO console, and logged in. But instead of seeing the console main page, the login page appeared a second time, with the user name and password fields blanked out.

The issue has to do with cookie handling. Dennis noted it in his blog entry here.

Well, it turns out getting OpenSSO Enterprise 8.0 to run on this release of GlassFish is a snap - if you know the workaround. Here are the steps for Solaris OS:

1. Obtain the GlassFish v3 Prelude Release from https://glassfish.dev.java.net.


2. Run the glassfish-v3-prelude-unix.sh command (which is what you obtained when you downloaded GlassFish). Specify installation options as needed. The rest of these instructions assume that you specified /opt/glassfish as your installation directory.


3. Start the domain administration server: /opt/glassfish/bin/asadmin start-domain domain1


4. Start a browser, then start the GlassFish administration console (http://zone04.example.com:4848) and log in to the console.


5. Click Application Server (in the left window pane), then the JVM Settings tab, then the JVM Options tab.


6. Click the Add JVM Option button. A new line opens up.


7. Add the following option: -Dcom.iplanet.am.cookie.c66Encode=true (this is the workaround).


8. Change the -client option to -server, and change the -Xmx512m option to at least -Xmx1024m (as documented in the OpenSSO Installation and Configuration Guide.


9. Log out of the GlassFish admin console.


10. Restart the GlassFish DAS:
    
    /opt/glassfish/bin/asadmin stop-domain domain1
    /opt/glassfish/bin/asadmin start-domain domain1


11. Deploy the OpenSSO web application and configure it.


12. Start the OpenSSO console and log in. This should take you to the console's main page.

BusinessWeek published an interesting article on Sunday titled "U.S. Is Losing Global Cyberwar, Commission Says".  If you are interested in Identity Management or IT security this is an important topic.  The plenary session was held this afternoon with press releases flying across the internet.  You can find the MSNBC version here.  BusinessWeek did a nice job of scooping the report and summarizing some of the recommendations which include creating a "CyberSecurity Czar".  I am not sure we need more Czar's but if you are interested in the details of the report please take a look at the full report here.

OpenSSO can be integrated with .NET applications. Here are some ways to achieve single sign-on or attribute sharing:

1. Install the IIS agent to protect the .NET application, and install OpenSSO as the service provider with the .NET application. The identity provider could then achieve single sign-on with the .NET application, and attributes can be passed down, as part of the HTTP header, to the .NET application.
2. Securely exchange attributes using the .NET client API provided by OpenSSO for integration with the .NET application. This makes use of the SAMLv2 and the Virtual Federation Proxy feature of OpenSSO.
3. Deploy Active Directory Federation Services as the service provider with the .NET application. OpenSSO would act as the identity provider. Use the WS-Federation protocol to achieve single sign-on with the .NET application.

While ruminating these options, enjoy Cheap and Cheerful from The Kills EXCELLENT third album Midnight Boom.

I just presented OpenSSO in the Clouds [PDF] at the December meeting of AWSome Atlanta, a technology meetup to discuss Amazon EC2, S3 and other cloud technology. John Willis, Michael Coté's co-conspirator on the Redmonk IT Management Podcast, invited me to speak here after Daniel and I did a video interview with Coté a couple of months ago. A nice bunch of folks here in Atlanta, pretty technical but very focused on the practical aspects of deployment. I promised I'd post my slides, so here they are.

This is also the point at which I'll switch off the OpenSSO Amazon EC2 instance I created in preparation for tonight's event. As I mentioned in my presentation - watch this space for further developments around OpenSSO and the cloud!

Software as a Service(SaaS) has evolved as the service delivery mechanism of choice in the internet age. Managed Services and SaaS provide enterprises options for deployments that deliver levels of service to fit individual needs and offload overworked IT departments.  For key, business critical software, though most large companies have still been using the traditional locally stored licensed software, they are keeping a close eye on the SaaS space. Given the current economic scenario and the pressures, SaaS adoption could accelerate in the coming days as a means of limiting maintenance costs and as a way of addressing business priorities.

Salesforce and Google have been leading and early adoptors of SaaS based software delivery mechanism. Salesforce.com offers an alternative to locally run sales force automation (SFA) packages; Google provides productivity applications via Google Apps Premier Edition. Here's an earlier screencast on usage scenario of these SaaS applications with Single Sign-On. 

For Single Sign On, both Google Apps and Salesforce have support for the OASIS Security Assertion Markup Language (SAML) standard, that can be used to provide single sign-on system access to these two SaaS vendors. This lets customers who invested in SAML to implement single sign-on in Salesforce and Google Apps easily and cost-effectively. Also, SAML never sends passwords to Salesforce and Google, so it is inherently more secure than other authentication mechanisms.

These 2 new Sun Developer Network articles(Google Apps article / Salesforce integration article) describe the steps involved in configuring and using OpenSSO for SAML based SSO integrations with Google and Salesforce, in detail.

Certainly take a look at these very interesting articles and give the integrations a try!

Here is some information regarding how you might configure OpenSSO sites and servers for a sample SAMLv2 deployment. The requirement in this SAMLv2 deployment is to allow normal users to access OpenSSO via pure SSL and administrative users to access OpenSSO via SSL with certificate authentication. The deployment is a straight forward setup (using two instances of OpenSSO and Glassfish, and one load balancer) except for the following:

1. The requirement for certificate authentication for one group of users and LDAP authentication for t'other group of users.
2. The users are split into two domains: one for the identity provider and t'other for the service provider. The identity provider will authenticate, and the service provider will control access using a J2EE policy agent.

The load balancer should be configured with two listening sockets but there should be only one configured Site in OpenSSO. The Site configuration does not need to know both listening sockets as long as the two configured listening sockets (in this example, port 1443 and 2443) point to the same instance of OpenSSO. For this deployment do the following configurations.

• On both instances of OpenSSO, under the Configuration --> Servers and Sites tabs in the console, create one New Server for each OpenSSO instance as in:
  • https://osso1.server.com:1443/opensso
  • https://osso2.server.com:1443/opensso
  Create a New Site with your chosen name and a Primary URL that points to the first virtual IP of the load balancer as in https://lb-vip1.server.com:1443/opensso. Click the created Site and add the second virtual IP of the load balancer, https://lb-vip2.server.com:1443/opensso.
  Click each server previously created to add the created Site as the value of the Parent Site attribute.
• In the first instance of the Glassfish console, configure two listening sockets:
  • https://osso1.server.com:1443/opensso
  • https://osso1.server.com:2443/opensso
  In the second instance of the Glassfish console, configure two listening sockets:
  • https://osso2.server.com:1443/opensso
  • https://osso2.server.com:2443/opensso
• In the load balancer, configure two virtual servers that each points to two different pools:
  • Virtual Server 1
    https://lb-vip1.server.com:1443 points to two different pools:
    • https://osso1.server.com:1443/opensso
    • https://osso2.server.com:1443/opensso
  • Virtual Server 2
    https://lb-vip2.server.com:2443 points to two different pools:
    • https://osso1.server.com:2443/opensso
    • https://osso2.server.com:2443/opensso

And from SSL to SSQ, here's Synthecide. Stacey Q was lead singer of this mid-80s Berlin-sounding synth band before she went solo with the Madonna-sounding Two of Hearts. At that point, everyone decided to hate her and she was never heard from again.