JBoss Federated SSO: Does it support?

[arjundhar]

Hi,
I'm in the process of evaluating certain OpenSource Solutions. I've looked at CAS, JOSSO and OpenSSO. Also our owd solution but then the security audit on that would be more stringent and hence consume more time, apart from development.

For better or for worse my client has bought support from JBoss. So we would rather go for a JBoss solution.

Now, I read about JBossSX and then the JBoss SSO.

Q1) Is JBoss SX a pre requisite for JBoss SSO??
Q2) If so, how and why? (For HOW a link would suffice that talks of integration). (I hope not!)

Q3) More Importantly, I'm lookin at the following features in JBoss SSO:
3.1. Ability to attach a Web filter (Servlet 2.3 Sepc) in the 3rd part App which can be on any App/Web Server. The filter will communicat with the SSO server. This reduces integration cost.
3.2. Do I have to recompile it for JDK1.4
3.3. Is there a dependency on a specific JBoss App Server version or can we run it on a JBoss 3.2.7 also?
3.4. Can I run it on Tomcat?
3.5. Configure, SSO sessions time outs
3.6. Attach a Bean(s) to a SSO session; so we can expose a serivce to request for information about that session without hitting the database
3.7. Configure things like Person can login once with credentials only, or can have multiple login-ins.
3.8. SSO Sessions should extend or be normal Web Server sessiosn or if not then provide support for clustering, for session replication.
3.9. Whats the underlysing principle behind the SSO? Like CAS is based ona Kerberosv5 based protocol.

... Would appreciate help in any way.

Thanks,
Arjun

[soshah]

Arjun-

Here is the detailed documentation for the JBoss Federated SSO project http://labs.jboss.com/wiki/Jbosssso

As per your questions:

Q1) Is JBoss SX a pre requisite for JBoss SSO??

JBoss SX is not a requirement for JBoss SSO. It supports both JAAS based authentication mechanism as well as an custom authentication mechanism. The wiki has detailed information related to both approaches

3.1. Ability to attach a Web filter (Servlet 2.3 Sepc) in the 3rd part App which can be on any App/Web Server. The filter will communicat with the SSO server. This reduces integration cost.

With JBoss SSO, Single Sign On orchestration/Token management is provided out-of-the-box using Tomcat Valve approach. This mechanism takes care of all communication/secure exchanges between your web application and the SSO Federation Server. All your application needs to do is provide the web application integration discussed in the wiki. Hence, you don't need a Servlet Filter in your web application to communicate with the SSO Server

Do I have to recompile it for JDK1.4

The framework in its current codebase is fully compliant with JDK1.4. It should also run out-of-the-box in JDK5 as well

Is there a dependency on a specific JBoss App Server version or can we run it on a JBoss 3.2.7 also?

The JBoss AS versions supported are 4.0.4 and 4.0.5. Integration with newer versions is on the roadmap. Backporting for older versions is not

Can I run it on Tomcat?

No at the moment. It runs within the Tomcat integrated with the AS

Configure, SSO sessions time outs

Yes. This is the exact same as your Tomcat's http session timeout of your application. And if one application is logged out, the Federated Logout function performs corresponding logout in the other web applications as well

Attach a Bean(s) to a SSO session; so we can expose a serivce to request for information about that session without hitting the database

Not sure if I understand. Are you referring to the availability of an HttpSession for your web application here? Whats the usecase? Think of JBoss SSO as a black box layer on top of your web application for orchestrating Single Sign On between a group of Federated web applications. Hence, nothing changes for your web application functionality including your use of HttpSession etc

Configure things like Person can login once with credentials only, or can have multiple login-ins.

JBoss SSO does not dictate the application requirements for your login usecase. It comes into play (SSO orchestration) once an authentication is successfull and a Logged In Principal is established

SSO Sessions should extend or be normal Web Server sessiosn or if not then provide support for clustering, for session replication.

Web Server Sessions remain as is. Nothing changes here. Your web application is completely unaware of the presence of an SSO layer, and all facilities like HttpSession clustering/replication are available the same way before the SSO layer was integrated

Whats the underlysing principle behind the SSO? Like CAS is based ona Kerberosv5 based protocol.

Underlying principles for the approach is:

1/ De-centralized approach using a Federation of independent web applications that could possibly even live in completely different web domains.

2/ A standard based approach using SAML so that independent web applications like say your companies internal portal and your SAAS provider (like SalesForce) can exchange SSO Assertions and Trust Handshake securely

3/ One difference I have found with CAS, JOSSO etc is integration is not so flexible. Plus, it requires authentication UI to be shared by redirection to the central UI and back. With JBoss SSO, each web application is in full control of their authentication mechanism, authentication logic requirement, UI etc. Its only once a user is authenticated within the web application, the SSO orchestration starts. (No re-directing back and worth needed). Besides flexibility, the central UI apporach suffers from a scalability issue as well

Hope this helps

Thanks

[arjundhar]

Thanks Sohil. Thats was very helpful indeed.

On a less critical note and as tech discussion:
Once a person has logged in VIA SSO, I assume JBoss SSO design creates a session on the SSO server. So that for a "Passprt" like token functionality; when a person clicks a link on the browser (say) and moves to another application, one cannot pass credentials. There would be some sort of a session cookie passed on with an encrypted key ..or some similar mechanism.

Now, the point being that if the 4th App needs to get some info from the SSO service (like users phone number)*; it can pass the key, thus not compromising on the actual user credentials. Hence that key reference would be maintained on an SSO session.

*why would an SSO return phone number?
Ans) Because one of the ideas of SSO is also maintain common credential data which may include additional fields. In that scenario a service may request for additonal info. Now this part would not be out of the of box, thats ok. But the rest of the discussion is valid.

The issue that kicks in is that SSO sessiosn and local sessions may be out of synch. And thats ok, coz if my SSO session times out in 30 minuts. I may not want o enfore that on the session of a local application which may have its setting for 3 hours.

If the person needs to move to another site, then sure he wil require re authentication. This is how some SSO get the job done.

So thats what I was referring to as "SSO Session".

But I really appreciate the response, it has me excited to dig through the code. :)

...As for the Valve. I saw the code; but Valves connect to the container (engine, host, context), while filters to servlets. Anyway, can always tweak that code basedon our requirement.

Thanks! What I really am happy about is I dont need to JBossSX at this phase to complicate my life :) Thanks again.

[arjundhar]

BTW I tried to build the jboss-sso-1.0CR1 source. In the jboss_saml module I had two issues with the build. I solved them, documenting them.

1. The opensaml-1.1.jar was giving a version 0.49 issue. So I downloaded the OpenSAML src and re-compiled and JAR'd it.

2. There is a library dependency on /thirdparty/xml/lib/*.jar; so included a line in the build.xml for jboss_saml

<path refid="xml.classpath"/>

in the configure-libraries target.

[arjundhar]

I have a Question:

In the Wiki (http://labs.jboss.com/wiki/StartFedSSO) for installation and testing; it says to copy the default configuration and start the server again:

Now create an exact same copy of 'default' configuration and name it 'default2'
\

run -c default2 -b node1.jboss.org (for cross domain test) or run -c default2 -b node2.jboss.com (for same domain test)

... Why would I run two instances of the server to test? To test shouldnt I be just deploying a random test WAR and have the "VALVE" configured. Any request to that application/WAR would require SSO. If I need to run SSO instances on each application server, whats the point?

Am not able to get it!?!

[aprilea76]

Hi all,
do you know if JBoss SSO Federated 1.0 RC1 is compatible with JBossAS 4.2 and 4.3 ?

Many thanks
Antonio A.

[soshah]

Arjun-

.. Why would I run two instances of the server to test? To test shouldnt I be just deploying a random test WAR and have the "VALVE" configured. Any request to that application/WAR would require SSO. If I need to run SSO instances on each application server, whats the point?

You can certaily deploy all your wars that are part of the SSO Federation in the same instance of JBoss Server and have them all work just fine.

This example of deploying in a different instance is used to demonstrate that your applications can be deployed anywhere you like including in completely different physical servers in a completely different web domain.

In a nutshell, SSO between apps within the same server is trivial (In fact for this setup, you can probably just use the Tomcat SSO). Its when they can be completely location/domain independent, and then the framework truly shines ;)

Thanks

[soshah]

Antonio

do you know if JBoss SSO Federated 1.0 RC1 is compatible with JBossAS 4.2 and 4.3 ?

So far the release supports till 4.0.5. Higher versions will be supported soon.

Thanks

[bhvijay]

can u  tell me is it possible to run different servers in jboss,

i have 3 applications and i need to make this as federated sso . one application in weblogic another is in tomcat another is in jboss,

is it possible to make federated sso in jboss?

thanks for reply..............

[bhvijay]

hai sohil shah am waiting for u r relpy.

we have already some application in different servers and i need to make this application as federated single sign on.

explanation:

     first application is in weblogic

     second application is in tomcat

     third application is appserver

    forth.................................

can i able to make this as federated sso

if yes tell me how?