I am in the middle of setting up SSO in our infrastructure and I am wondering if people would more experience could share their learnings.
I already have a reverse-proxy in-front of our system.
We have several legacy java apps running on tomcat
We have SPA apps as well written in JS
We have few APIs that will also need to be protected
I have two ways to set SSO up for us.
set up SSO on the reverse proxy using mod_auth_openidc so our gatekeeper makes sure that anyone who is hitting our services is already validated.
add a keycloak libs to each individual service
My preference is to set this up on the referse proxy.
Are there any disadvantages / best practices when it comes to this?
For legacy apps I would just use the HTTP headers added by the reverse proxy to find user details
For the new apps I would like to use the keycloak libs to get user details.
I do not want to go down some routes which is obviously problematic. So Any tips so that I can save some time are very welcome.
So far I have come up with the following list
pros to use a proxy server and mod_auth_openidc
Single place to handle all auth specific configuration
Abstracts out the implementation detail of the SSO. E.g. we do not need to integrate keycloak into each service. In my opinion this could cause issues if we decided later to actually move to a different SSO. ( I know this does not happen often )
cons to use a proxy server and mod_auth_openidc
an additional piece of software to maintain ( bugs etc )
possible extra checks on credentials if the app also integrated with keycloak ( not required it is possible but only needed if keycloak specific features are required in the app and those not available in the headers )
I would be interested in other's opinion on the pros and cons?
Thanks
Related
I've been scavenging around the internet for information about multiple security configurations regarding combining oauth and basic authentication.
I'm not sure it's really what I want, but I decided to do some research to figure out weather it was a good idea or not.
The question is really simple. Can you combine Oauth authentication and basic authentcation in your spring boot application. So that some endpoints uses one type of authentication and other end points uses another type of authentication.
and does it make sense to do so?
The idea behind it is that I want to have heavy(oauth authentication on my endpoints if another party is calling my application) however if i'm calling my endpoints through a frontend application that I control. Should that then still use Oauth, or would basic authentication be alright?
to sum up. Is it possible to have "/getCustomers" secured by oauth, and "/ping" completely open or with another authentication type.
I hope this makes sense, I kinda trying to figure out what I want with this and if it even makes sense.
to sum up. Is it possible to have "/getCustomers" secured by oauth, and "/ping" completely open or with another authentication type.
To sum up, yes you can.
You can configure multiple entry points with same http element, you can configure different http elements, and you can even configure several WebSecurityConfigurerAdapter according to spring security reference documentation.
https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#multiple-httpsecurity
We have a MicroService based Architecture where each service has a REST End point. These services talk to each other via REST.
However I noticed that a lot of developers have directly started calling these Services in the Javascript code of our Web Application. I want to know if it is recommended to access these MicroServices over the Internet OR they should be hidden behind a Facade layer. Of course all the end points are authenticated but all Web application users can find these end points once they do a F12.
thanks,
Abhi
I would not do that for the following reasons
Security. You are exposing your endpoint as is and it allow other people to know quite a lot about your endpoints then what you rather want them to know. Authentication is ok, but are still open for DDOS for your individual services, out of turn calls, unexpected load etc.
Service Discovery. By allowing access to the endpoints directly you are basically forcing dev to bind themselves with a given URL. This may work but since it is restricting you to make changes in future to your URL etc its better not to do it. By having a layer in between you will be required to change one url if ever required
Code Duplication There are quite a few cross cutting concerns when it comes to URL handling like request logging, https stripping, authentication, prevention of DDOS, request limiting etc. By having one common layer before your services you can manage all these at that one place rather than doing each of them for each services
If you think any of these are or could be major concerns that you should add an additional layer in between and route your internet facing api via that.
Is it possible to configure wildfly such that users and agents have "optional" security?
In essence I want form authentication for a web page, silent basic authentication for my services. Most unfortunately, one component of my ecosystem cannot call with basic headers.
That being said I have a work around but it will take some time to implement. For the time being I would desire to basically have optional security. So everything can play nice in the interim.
I know I could change my authentication module to allow everyone through. But with form turned on, requests without a basic header ram back the web page to log in with.
Thanks for any good tips or tricks.
Edit: This would be possible with Spring Security. Using WildFly's inbuilt security mechanisms with undertow seems to limit your flexibility. So much is handled up front before you reach your code, you really are stuck.
However, with spring security, everything is implemented as filters and so you can check the request context for user agents and all kinds of things, and make decisions about each request as you want.
Obviously this wouldn't be a production solution but in development, like was my case, I could have let any request with user agent XYZ run as admin, for the time being.
I have since migrated to Spring Security for our web app security management.
So the short answer is no. The short answer is still no, but the slightly longer answer is to stop using Wildfly's in built security and use Spring Security.
In the long run you could probably create your own undertow servlet extension that would validate authentication or default to admin credentials. This is going to be a lot of work, and spring security has already done a lot of work for you.
We ended up spinning up duplicate of our services without any authentication that our trailing component could call in the meantime. If you don't want to use spring security this is still the best solution I have
I need to implement Single Sign On feature for several internal web applications which are not deployed on the same domain.
Is federation a good solution in my case? Or it is only used if I want to federate the authentication to an external IdP.
I mean I want to create a custom WIF STS and make all the applications claims-aware RPs.
I'm thinking of it because I don't want to use custom solutions or third party libraries. WIF seems to have a straightforward solution integrated with .Net Framework.
Is my suggestion correct? Or this is an incorrect use for WIF.
Yes - a solution with WIF / STS will work even if it's only internal.
Beware of security if you roll your own.
You may want to look at ADFS or IdentityServer.
Going this route will make your life a lot easier.
I am looking for an SSO solution that can be customized according to our needs.
From what i saw over the internet it seems that Shibboleth and JOSSO are solutions that just need to be installed and configured. My question is to what extent can they be customized to use with web apps.Please consider following points.
control over cookies and session management
integration with existing authentication mechanisms being used for the app (e.g. two factor authentication)
collection of data from the user at the time of registration.
Suggestions on any other frameworks and approaches are welcome