I got a Spring Boot 2 Reactive Web Application that currently has a JWT-based authentication system. Now I would like to add a LDAP backend for authentication and allow Single-Sign On (SSO) via Kerberos.
It seems Kerberos and LDAP support is currently limited to webmvc and no dedicated reactive version is available.
Since documentation about integrating all 3 components (WebFlux, LDAP + Kerberos) together in one application is quiet rare I would like to ask if someone of you already took the attempt to set-up such an infrastructure and is willing to share an example how to do.
I ran into the same issues with SAML. I haven't seen any progress on porting these sub projects to be supported in a webflux environment. The obvious approach seems to me to rewrite all servlet filters to WebFilters.
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 have site in grails, and now I need to add API support. Third party application will be using it to access resources. I thought of using Spring Security OAuth2 plugin (Plugin link) for that, but I would like, for now, to skip asking user to authorise application (Is that possible?).
Also, I found Spring Security REST (Plugin link).
I have in plan creating also my own mobile application, so I am not sure what is the better solution. Or is it better to use OAuth2 for third party applications and then REST plugin for my own app? What are benefits of one plugin compared to the other?
I am developing a Spring boot application for payment using microservices, which will be consumed by mobile application and web application.
1) Users need to be authenticated for accessing the mobile app
2) Third party mobile apps using my services need to be authenticated (with my app)
3) Web applications using my services need to be authenticated.
My user details will be there in DB or LDAP. I have plans for integrating IBM API management and the deployment will be in on-premise servers. Based on this requirement how I need to design and implement my solution?
After going through different blogs I am confused now. So a proper guidance will be very helpful for me.
Your question is a bit vague or too broad, but ...
Using LDAP does not scale well, consider using NoSQL alternatives as those are closer to the principles of microservices.
See:
Microservice Authentication strategy
http://presos.dsyer.com/decks/microservice-security.html#slide6
https://www.quora.com/Microservices/How-do-I-handle-authentication-in-a-microservices-architecture-with-the-front-end-decoupled-too
How to secure REST services (OAuth) with Spring Boot?
The closest I can get is:
http://spring.io/guides/gs/securing-web/
http://spring.io/guides/gs/authenticating-ldap/
You could add the OAuth2AuthenticationProcessingFilter pretty easily to a Boot app. The closest sample would probably be the spring-boot-sample-secure, since it explicitly adds a WebSecurityConfigurerAdapter, which is what you'd have to do. There is no native autoconfiguration support for OAuth in Spring Boot yet (but please feel free to add it). It is on the roadmap, but unlikely to get a lot of attention unless more people ask for it.
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).