I'd like to implement a Single Sign-on (SSO) authentication layer in my Spring-based application with the aim of supporting authentication and authorization from different security domains.
I've chosen Shibboleth as IdP, but I have yet to identify what I will use for the SP.
The choices are:
Spring Security SAML Extension: component enables both new and existing applications to act as a Service Provider in federations based on SAML 2.0 protocol and enable Web Single Sign-On. Spring Security Extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used to connect with Spring Security SAML Extension.
Shibboleth (also as SP): Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components.
So, I've some questions:
Is it a good idea to use directly Spring SAML as SP in terms of
scalability and maintainability?
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)?
Where do I define the roles (for each scenario)?
Which is the worthwhile choice?
Best regards, V.
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.
Related
I have a Java Spring MVC application (note that its not spring boot).
We have a requirement to implement SSO for the users of our application. I did some research, the identity provider (IDP) in our case is Azure AD. The service provider would be my application in this case. I am thinking of using SAML protocol for SSO.
Also note - The application is http based (not HTTPS)
What I've done so far -
I've created an Enterprise Application on Azure and configured entityId and replyURL. I also added a user for this application.
Where I'm stuck -
Although I did read the related Spring documentation to achieve this, since I'm a newbie here, I still don't have a clear path as to how can I take this forward in my application. I found some solutions, they seem to be examples for spring boot. Can someone please help me with guides as to how this can be done in Java Spring? Which maven dependency I could use and any sample example to start working with SAML? A step by step explanation would be highly appreciated, thankyou.
Also, any other options than SAML would also be fine.
The Spring Security SAML extension (https://docs.spring.io/spring-security-saml/docs/1.0.0.RELEASE/reference/html/index.html) had an example web app. You may read the referenced doc and apply it to Spring Security SAML. It should not be too much difference.
I’m very glad to register the flow in the event of implementing Azure AD B2C OIDC/OAuth protocol with existing Spring MVC architecture.
Below Spring docs reveal that how was our existing project's spring-security layer being served in the context of filter-chain.
Pre-requisites
Authentication Filter - Form Based Login with Legacy IDP
Authentication Manager – Providing the user details authorities along with http session object
For accomplishing this Azure B2C Integration, we've gone thro' lot of repos but most of them are relying with Java config based but we were interested on Spring namespace with limited code/architectural change.
Then finally we came to the conclusion that how to extend the spring default auth-filter/manager for getting valid session object from security context based on the Azure provided (id/access) token after the successful user authentication.
Customizing Spring-Security
The detailed documentation on how to extend auth-filter/manager is available here with © reserved by terasoluna.org
We customized the spring security in such a manner that auth-filter will carry the token_validation against the given token from Azure and authentication manager will extract user details such as roles/privileges w.r.t to the object-id mapped in our DB's user entity.
Once the Spring security customization is done then we can able to integrate the Authorization-server [Azure in our case] and Resource-server [Existing Spring Application] by following the conventional methods.
I am currently writing a Spring Boot 2.x application that by default is authenticated by the app's oauth2 authorization server. However, I would like to add support such as the user could configure the app to use their SAML identity provider/asserting party (like Active Directory) as an alternative to the default OAuth2 authentication server.
What I can see is that developers would write a WebSecurityConfigurerAdapter with .saml2Login() or .oauth2ResourceServer(o -> o.jwt()) but I would switch between the two at runtime.
Note that I will secure the same set of URLs/APIs. It's just that I want the user to be able to choose what to use. Also as a disclaimer, I do not have experience with SAML.
Would this be possible to do in Spring Boot? Hope someone could say definitively if this is possible or not.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
I'm going to be undertaking a large project for a client of mine. I need to write an IDP (identity provider) that will handle single-sign-on to multiple apps by a number of different authentication methods (such as SAML, OAuth, Form-based auth, HTTP Basic auth). I'd also need the ability to add in additional types of authentication as the app grows.
The basic idea would be that we'd have three different components to the app. One would be the IDP. Another would be a data-store that contains user accounts, the apps they want to use, etc. The third would be a GUI front-end that allows users to sign into apps.
It seems that there are some existing gems that handle authentication, like https://github.com/onelogin/ruby-saml and https://github.com/intridea/omniauth. My question is, am I overcomplicating this project -- would I just be able to use existing gems like these to act as the IDP, or is this a project where I'd need to read specs and implement them myself in Ruby?
Using something like SAML toolkit for Ruby on Rails adapted to work with ADFS server, you can integrate with ADFS. Now you can leverage ADFS features:
Interface with Facebook etc. via Azure ACS
Interface with Azure Active Directory and hence SSO to SaaS applications
Azure Active Directory Multi Factor Authentication
BYOD via the Web Applications Proxy
OAuth on ADFS 3.0
and so on. The list is expanding all the time.
Once you hook into these standards. you just inherit all the new features as they are released.
I'm currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).