In order to implement SAML do I need Shibboleth SP installed on my host?

Question

I got a couple of SAML implementation questions to clear up my confusion ...

I need to implement SSO in a java web app.

1. In order to do so, do I need Shi

Answer 1

Yes, you should install SP in your server or your machine. And it would depend on your webserver, such as IIS or Apache.

Answer 2

Updates to address your edits:

Here are some SAML 2 options you can use.

• PingFederate https://www.pingidentity.com/ GOOD stuff to help you understand SAML and SSO. Commercial and used by lots of companies.
• JOSSO All-Java http://www.josso.org/confluence/display/JOSSO1/JOSSO+-+Java+Open+Single+Sign-On+Project+Home, LGPL 2.1 or later
• LASSO Java APIs over native implementation. http://lasso.entrouvert.org/ Dual licensed (Free only for non-commercial use).
• OpenAM All-Java http://java.net/projects/opensso/, CDDL 1.0
• Shibboleth SP C++, http://shibboleth.internet2.edu/, Apache License, Version 2.0.
• OpenSAML libraries Java or C++, https://wiki.shibboleth.net/confluence/display/OpenSAML/Home/ Apache License, Version 2.0.
• Defunct OpenSSO (became OpenAM) All-Java http://java.net/projects/opensso/, CDDL 1.0
• Shibboleth IdP All-Java This is not an SP, just an IdP, which is useful for testing your SP.

Shibboleth SP is a product that implements SAML 2.0 for you, but OpenSAML is just a library with which you could implement a SAML 2.0 solution. The library itself is low-level, and is not even close to being an SSO solution. OpenSAML is not a SAML 2.0 solution by itself.

To use OpenSAML or any SAML 2.0 solution, you will need to exchange metadata as noted below. With OpenSAML you'll have to hand-generate an XML file for your own MetaData, too. It will be a lot of work as noted below. SAML 2.0 products will generate that XML MetaData file for you and also generate the required RSA keys used for encryption and signing of the SAML 2.0 Assertions. With OpenSAML, you'll have API support for loading parts of the XML files and APIs for generating and parsing your Assertions, but you'll be writing the Java code that actually builds the SSO interaction.

The SP does not necessarily need ActiveDirectory/LDAP, but you will need some type of directory in your web application that keeps track of users. If your web application already has a notion of users with some identifying information that you can use to correlate them with the IdP's notion of users, you can just map those in your web application based on Attribute values in your SAML 2.0 Assertions. (If your web application doesn't care who the users are, then you can simply allow access to the application based on the user being "valid".)

--

Integrating Shibboleth2 SSO with a Java web application is not too difficult. Using OpenSAML to implement the SSO would work, but it would be a lot more effort than integrating an Apache server with Shibboleth.

Using Shibboleth requires that you have Apache2 with the Shibboleth module enabled and that you have the Shibboleth SP daemon installed. Typically, those would be together on the same box. If you're using Tomcat to host the Java web application, then I recommend that you use mod_proxy_ajp to communicate between the Apache2 HTTP server and Tomcat. That way you can pick up the Shibolleth-provided variables as servlet Request attributes. (You have to set the variable prefix to "AJP_" in shibboleth2.xml.)

The Shibboleth SP package already handles all of the standard SAML SSO scenarios you can expect to encounter, but trying to implement even one of those with OpenSAML directly in your Java application is fraught with peril both from getting it to work and also from making it secure. You'll also increase the size of your web app if you use OpenSAML. It's worth noting that the Shibboleth SP is not written in Java, so you will not have examples of using OpenSAML for that, but you might be able to gain some insight by looking at the Shibboleth IdP code, which is a Java web app.

In either case, you'll need to exchange your SP metadata (easily created with the Shibboleth SP package) with your Identity Provider and also get the Identity Provider's metadata on your SP (also easy with the Shibboleth SP package as you simply set up a MetadataProvider).

The Shibboleth documentation online will help you a lot once you get used to using it.

I think you'll have much greater chances of success if you can use the Shibboleth SP package rather than implement a SAML 2 SSO solution with the OpenSAML libraries. I can't speak to the other all-Java SAML 2 SSO solutions, but they all seem big and overly enterprisey compared to a simple Shibboleth 2 SP.

Answer 3

You should post such questions to the relevant mailing lists run by the Shibboleth Project.

OpenSAML is a very low level toolkit for implementing SAML solutions, Shibboleth is a SSO package for web applications supporting SAML that happens to be built with OpenSAML. Building security solutions is complex and requires expertise. If you don't have that expertise, you'll do a bad job of it, and OpenSAML is not documented such that a typical developer could build a solution from scratch.

Consider using a complete implementation, whether it's Shibboleth or something else. If you can't live with Apache and native code and need Java, then you should try one of the extant Java SP options that exist. Even if they were inadequate, you should build on them and not duplicate them.

Answer 4

What will be needed to use OpenSAML? Just the IdP url and a registration with the idP?

You need Java and a web container, and include opensaml library in you war.

You need to cache IdP metadata locally or look it up each time when you want to send AuthnRequest or process SAMLResponse. Also you have to register your SP metadata on IdP side.

If you are using Shibboleth as your IdP, the SP metadata should be setup in conf/relying-party.xml file.

Do I need to provide an SP directory, e.g. ActiveDirectory/LDAP?

In order to login in IdP, you need to set up ldap or database server on IdP side and config it in conf/attribute-resolver.xml and conf/login.config.