JOSSO Single Sign-On 1.2 Released

Discussions

News: JOSSO Single Sign-On 1.2 Released

  1. JOSSO Single Sign-On 1.2 Released (17 messages)

    JOSSO, or Java Open Single Sign-On, is an open source J2EE-based SSO infrastructure aimed to provide a solution for centralized platform neutral user authentication.

    JOSSO main features include:

    * 100% Java
    * JAAS-based Transparent Single Sign-On across multiple applications and hosts.
    * Built-in with a Pluggable Framework to allow the implementation of multiple authentication schemes and stores.
    * Runs in JBoss 3.2.6 application server.
    * Runs in Jakarta Tomcat 5.0.27+ .
    * Provides Identity information to web applications and EJBs through the standard Servlet and EJB Security API respectively.
    * Supports Strong Authentication using X.509 client certificates.
    * Comes with a Reverse Proxy component that can be used to create n-tier Single Sign-On configurations.
    * Allows n-tier configurations using multiple strategies.
    * LDAP support for storing user information and credentials.
    * Database support for storing user information and credentials.
    * XML support for storing user information and credentials.
    * Avalability of Jakarta Tomcat and JBoss bundles.
    * Client API for PHP. This allows to build SSO-enabled PHP applications.
    * Client API for Microsoft ASP. This allows to build SSO-enabled ASP applications.
    * Compatibility with Apache Pluto Portlet Container
    * Standard Based: JAAS, Web Services/SOAP, EJB, Struts, Servlet/JSP.
    * Commercial-Friendly. Released under the BSD License.

    JOSSO Home Page

    Download JOSSO 1.2

    Threaded Messages (17)

  2. So much XML. I wish there was some documentation for a "Java code only" example, instead of so much about how to configure Tomcat and JBoss.

    I was also wondering if JOSSO can support AD via the LDAP protocol. It looked to me like it assumed all users would be in a single place on the LDAP server, whereas in my work environment, I have to authenticate users against 3 different AD servers, and on each server, the users could be in a number of different places, so it's a 3-setp process of 1) bind as a single known user 2) search for user to authenticate and extract dn and 3) authenticate given credentials with extracted dn.
  3. other options[ Go to top ]

    Yeah, I'm looking at the spring/acegi/cas route instead for sso. If anyone is looking for the available open source options in this space, here's a good list:

    http://www.manageability.org/blog/stuff/single-sign-on-in-java/view
  4. HAve you thought of using a virtual directory? This would make your 3 AD's look like one directory.
  5. I am not in control of the AD servers. I'm just a poor app developer in a SOXy world.
  6. Thats the great thing about a virtual directory. You can deploy it for the application without disturbing your AD deployment or your AD admins.
  7. So much XML. I wish there was some documentation for a "Java code only" example, instead of so much about how to configure Tomcat and JBoss.

    Actually thats the nice thing of being a "transparent" SSO, since JOSSO partner applications won't need to be any different from a standard web applications. There is no coupling with a propietary API, you just use the standard Servlet/EJB security API calls, such as as isUserInRole().
    JOSSO will take care of injecting the SSO user identity into the container.
    I was also wondering if JOSSO can support AD via the LDAP protocol. It looked to me like it assumed all users would be in a single place on the LDAP server, whereas in my work environment, I have to authenticate users against 3 different AD servers, and on each server, the users could be in a number of different places, so it's a 3-setp process of 1) bind as a single known user 2) search for user to authenticate and extract dn and 3) authenticate given credentials with extracted dn.

    JOSSO was never tested with Active Directory.
    Considering your configuration seems like you will need more than on LDAP identity store, each mapped to one of your AD servers.
    This is a quite particular case actually and its not supported at the moment but you could customize JOSSO using its pluggable framework.
  8. Actually thats the nice thing of being a "transparent" SSO, since JOSSO partner applications won't need to be any different from a standard web applications. There is no coupling with a propietary API, you just use the standard Servlet/EJB security API calls, such as as isUserInRole().JOSSO will take care of injecting the SSO user identity into the container.

    I understand it's not tied to a particular container, I was just lamenting the lack of a more nuts and bolts example in the documentation for someone like me who finds straight Java code more comprehensible. I would like to know how JOSSO does it's thing, not just the steps I have to take to set it up.

    For instance, the documentation talked about a session id that JOSSO stores, but how does a partner app access that session id? Cookies are normally tied to a host or domain, and so I assumed this meant JOSSO would have to use a fairly open ended domain match (*.mycompany.com), but I didn't actually see where it talked about that.
    JOSSO was never tested with Active Directory. Considering your configuration seems like you will need more than on LDAP identity store, each mapped to one of your AD servers. This is a quite particular case actually and its not supported at the moment but you could customize JOSSO using its pluggable framework.

    That's a good answer, especially since I've already got a component that deals with our AD messiness.
  9. SSO Protocol?[ Go to top ]

    Whats the protocol? Is it SAML or WS or propriety web service?
  10. SSO Protocol?[ Go to top ]

    Its a propietary SOAP-based protocol.

    Regarding SAML, RSA Corp. holds the patent of it, having a quite restrictive license agreement which we considered that at the moment is not compatible with the OS spirit.

    You can have a look at it here :

    http://www.rsasecurity.com/node.asp?id=2530
  11. SAML support is important[ Go to top ]

    According to the RSA statement at
    http://www.oasis-open.org/committees/security/ipr.php

    ". In the interest of encouraging deployment of SAML-based technologies, RSA offered to grant non-exclusive, royally-free licenses on a non-discriminatory basis for the RSA Patents."

    Even if a license agreement with RSA is needed by everyone who uses the JOSSO SAML binaries(There is no software that doesn't have one), why would this inhibit adoption of such an important standard as SAML?
  12. I also think SAML support is important, but I also beleive that, if JOSSO starts supporting SAML, users would probably prefer this option from the propietary (but OS) since its standard, provides interoperability an so on.
    The project would then be promoting the adoption of SAML in the OS community, commiting its users to it.
    What if RSA decides to change its license agreement, making it more restrictive, an year or two later ? Maybe charging for each deploy ?
    Also I'm not sure if the JOSSO bundles could carry a SAML toolkit just like that...

    It would be interesting then to see a SAML-like standard emerging from the OS community and adopted from it.

    All this doesn't mean that JOSSO will not implement SAML. We will probably see this support on future versions, along with Liberty Alliance integration.
  13. Regarding SAML, RSA Corp. holds the patent of it

    ***WRONG!!!***

    RSA holds a patent that they *claim* covers implementations of a particular aspect of SAML.

    This is /very much/ different from what you said.

    What it does mean is that it is up to implementors to decide whether they believe RSA will attempt to enforce their claims in court.

    My understanding from the grapevine is that there are quite a few SAML implementors that are ignoring RSA's specious claim on SAML.

    There are also several folks in the community that hope that RSA /does/ try to enforce their SAML claim in court so that it can be busted by a wealth of prior art.

    Be that as it may, it is self-defeating to not implement something openly specified like SAML just because you're scared of a silly peripherial claim such as RSA's. This is because given how the USA's broken patent system works, *anyone* could suddenly emerge from the bush and start waving around some patent claims and arm-twisting people to license it. This could happen with ANYTHING. For example, RSA could suddenly decide that their patents also cover the protocol(s) underneath JOSSO (http://www.josso.org/) and start demanding that everyone distributing and using the implementation must license it from RSA. I'm not saying that they are going to do this -- just that they, or essentially anyone else who has patents in the web single-signon area of art *could* do this -- and there are a LOT of entities besides RSA who have patents issued or filed in this area I bet.

    disclaimer: IANAL, YMMV, etc.

    regards,

    foobar.
  14. Is the on-the-wire protocol specified anywhere? I've searched the josso pages and haven't found it.

    FWIW, the history of actual security of proprietary, unspecified security protocols is rather poor -- due in part to the fact that such protocols aren't widely scruitinized, and thus are often buggy.

    regards,

    Anon.
  15. Collaborative Suite with SSO[ Go to top ]

    Will JOSSO work with Lotus notes / ms exchange ?

    Anyone knows any freeware tool to do the same?
  16. PHP support[ Go to top ]

    * Client API for PHP. This allows to build SSO-enabled PHP applications.

    Very niiice. I'll certainly be investigating this feature. It addresses a very specific and very recent issue that my company is exploring: rebuild a very nice PHP-based COTS app to make it tightly integrated with a larger Java-based app or somehow integrate them more loosely -- i.e., the dB will be the integration point. The only catch is, how to make the authentication work seemlessly between the PHP app and the Java app.

    I hope JOSSO is the answer.
  17. PHP support[ Go to top ]

    Regarding the Java tier, the SSO identity is injected by JOSSO into the container, so your web applications stay the same. You just need to declare the security constraints as usual using the standard web.xml file.

    In the PHP tier instead, since you haven't got a real standard web container, your pages need to interact with a JOSSO specific PHP API.

    You can have more information/samples about integrating PHP applications with JOSSO here :

    http://www.josso.org/php-howto.html
  18. Re: JOSSO Single Sign-On 1.2 Released[ Go to top ]

    Wat if i want to integrate it with Apache Geronimo.? possible? Sudhir nimavat