The main difference between the two is deployment scenario:
- Shibboleth SP plugins are deployed directly to the Apache/IIS web server.
- Spring SAML is embedded in your application.
Both have pros and cons.
- Is it a good idea to use directly Spring SAML as SP in terms of scalability and maintainability?
Spring SAML
- Offers great control over how authentication is performed and how the authentication process interacts with your application. You can e.g. create your own configuration UIs and dynamically add IDPs, create custom login screens as part of your application, have complete and easy control over error handling, easily support multiple IDPs, dynamically configured details of the SSO (requested AuthnContexts, NameIDs, bindings, authentication forcing).
- Easily parse received SAML attributes in various formats, support multiple authentication methods in the same application.
- Dynamically generate SP metadata, it provides limited multi-tenancy and supports profiles not available in all other options (e.g. Single Logout, Holder of Key, IDP Discovery).
- Seamlessly interacts with Spring Security which brings a set of benefits of its own. With Spring SAML you can also configure complete authentication and authorization policy directly in your application (e.g. which pages require authentication or not and when, role based access control to content, authentication step-up on dynamic conditions, ...).
- Allows you to deploy the application on any application server or container and behind any reverse proxy or web server with no affect on functionality.
Shibboleth plugins
- These are statically configured and typically interact with your application through HTTP headers. They decouple authentication logic from the application itself, so the only thing you need to take care of is acceptance of the headers and initialization of your application session with correct security context. The definition of which pages are secured is present on the IIS/Apache server and based on URL patterns which means that authentication and authorization policy is partly defined outside of your application.
- You need to make sure that the application can only be accessed through the web server (= prohibit all direct access) as that would allow forging of the headers.
- Doesn't require many changes to the application itself and can therefore typically be easily used with legacy systems.
- It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever
(JBoss 8.0 - WildFly)?
Yes, it is possible, but it will require effort. You could e.g. configure WildFly to set a shared domain cookie in encrypted format and verify the cookie in your Spring Security configuration.
- Where do I define the roles (for each scenario)?
With Spring SAML you define roles when processing the SAML Response by e.g. parsing of the SAML attributes. This is done by implementing SAMLUserDetailsService interface and plugging in to the samlAuthenticationProvider.
With Shibboleth you can forward attributes received from IDP to your application with headers and parse them in your application.
WildFly (probably) allows you to define security context and roles directly in SP with no need to configure this in your application. Such configuration might not be portable across application servers.
- Which is the worthwhile choice?
All options will enable you to perform WebSSO with SAML 2.0. People typically choose based on their requirements (e.g. customization needs), environment (used web server, application server), preferred development methodology (Java, .NET, other), used frameworks, legacy code. Both Spring SAML and Shibboleth plugins are used by many customers.
