I want to create a POC which demonstrate the SSO between two different application hosted on the different server and different machine(1.e. App-1 :- Websphere App server 7.0.0.15 and App2 :-Jboss 6.2 EAP).
Both the application share the same LDAP (user repository) so user can navigate from One Application to Another application (App-1 to App-2 or vice versa).
Please suggest me which SSO technique would be feasible in such setup.
If they apps are not deployed in the same cookie domain (check https://www.rfc-editor.org/rfc/rfc6265) or deployed in a public suffix (https://publicsuffix.org/) you can not use an SSO mechanism based on cookies unless the 'product' offers a way to perform CDSSO (like OpenAM). Then you may need to use 'SAML2' or 'OAuth2/OIDC'.
Related
I have a JavaEE application deployed in Payara application cluster with more than two nodes. Application uses Keycloak servlet adapter to enable integration with Keycloak. I have Keycloak 11.0 deployed in production with domain clustered mode. I have manually registered application cluster nodes under application clustering section of client configuration. I used ${application.session.host} in admin URL to enable keycloak to send back-channel logout call to appropriate cluster node. Load balancer with sticky session is used in front of application cluster to provide single node view and distribute requests. Everything works fine.
Now, I need to upgrade Keycloak to newer version, I am trying to upgrade to 18.0.2 (legacy version). However, newer version complies to OIDC Back-channel logout standard, and have separate config parameter under client configuration for back channel logout, separate then admin URL.
The problem is my clustered system doesn't work with this, back-channel logout param doesn't support ${application.session.host} in URL. Consequently, back-channel functionality breaks.
Moreover, Servlet Filter adapter implementation from Keycloak doesn't support handling back-channel logout as per my knowledge. I have implemented my own library to handle back-channel call: validating things as per standard and logging out appropriate session. For this sake, library stores sessions in an application scoped bean. In single node deployment of application, everything works but I don't have solution for multiple node application deployment from Keycloak regarding this, because Keycloak wouldn't know which node back-channel logout request would go, considering the fact that application deployment on each node is independent and client request distribution is configured with sticky sessions.
One solution is to use the Payara inbuilt Hazelcast datagrid to store the web sessions, and then any node should be able to handle the back-channel logout call across cluster.
But I am interested to know If keycloak has any solution on this.
I have 3 applications
old JSP based java app
Spring Boot webapp
SPA
5 java micro services REST API built using Spring Boot
I need to secure all of them at the same time. I have picked keycloak as it seemed like a good idea. As we are using Apache for reverse proxy. We have picked mod_auth_openidc to limit access to services at reverse proxy level.
We have built Extensions for Spring Webapp and old JSP app to use headers provided by mod_auth_openidc to handle active users and aithentication.
At this point now we have run into the issue that the we also secured the APIs using mod_auth_openidc headers. Although this has a serious drawback as APIs can not talk to each other just using JWT tokens as the reverse proxy needs them to be authenticated.
Should we secure the APIs using JWT only instead ?
Any mod_auth_openidc guru knows the best approach to this scenario?
I need the REST API to be able to talk to each other without any user interaction. E.g. only using tokens.
Our webapps ( JSP and SPA ) are always fully secured e.g. the user has to be logged in to access any part of it.
I would appreciate any suggestions.
Thanks
I have two Spring Boot web applications. Both applications have different databases and different sets of users. Also, both applications use Spring Security for authentication and authorisation which works properly.
At any given point I will have one instance of the first application running and multiple instances of the 2nd web application running.
I want to expose REST APIs from 1st web application (one instance running) and be able to use that REST APIs from 2nd web application (multiple instances running).
How do I make sure that REST APIs can be accessed securely with proper authentication and by instances of the 2nd applications only.
If you could change your security, I would recommend you to use OAUTH2. Basically it generates a token that is used in your APP2 instances to make the API calls.
You can see more here.
https://spring.io/guides/tutorials/spring-boot-oauth2/
http://websystique.com/spring-security/secure-spring-rest-api-using-oauth2/
But if you can't change your APP's security, you can continue using your current schema. In the APP1 you can create an user for the API calls, this user only has access to the API services. In your APP2 you need to store the credentials to access the APP1. Finally you do login into APP1 and invoke the API using HTTP client, you can use Spring RestTemplate or Apache HttpComponents Client.
SSL based authentication could be an option, if you seriously thinking about the security aspects.
Assume that you REST api exposed by App 1 is over HTTPs, then you can configure the App 1 to ask the client to give their SSL/TLS certificate when they try to access this REST API (exposed by App 1).
This will help us identify that the client is indeed a client from app 2.
Two More Cents:
In case if your App 1 REST API calls needs load balancing, NGINX should be your chose. The SSL client certificate based authentication can be offloaded to NGINX and Your Spring boot app no more worry about the SSL related configurations.
The solution we went with was to secure both using an OAuth2 client_credentials workflow. That is the OAuth2 flow where clients request a token on behalf of themselves, not a calling User.
Check out Spring Cloud Security
1) Secure your services using #EnableResourceServer
#SpringBootApplication
#EnableResourceServer
public class Application ...
2) Make calls from one service to another using an OAuth2RestTemplate
Check out Resource Server Token Relay in http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html which will specify how to configure an Oauth2RestTemplate to forward on security context details (token) from one service to another.
3) Service A and Service B should be able to communicate using these techniques if they are configured using the same Oauth2 Client and Secret. This will be configured in the applications' application.properties file, hopefully injected by the environment. Oauth2 Scopes can be used as role identifiers. You could therefore say that only a Client with Scopes (api-read, api-write) should have access to Endpoint A in Service A. This is configurable using Spring Security's Authorization configuration as well as #EnableGlobalMethodSecurity
Our IT staff refuses to install the SiteMinder agent on our application's IIS 6.0 web server, citing security concerns as it is a third-party software, as well as the possibility of high resource utilization impacting application performance.
They suggest that we set up an independent, segregated web server containing only a bare-bones IIS, the SiteMinder Agent, and a "shim" to authenticate login attempts.
This shim would be a single ASPX page marked to be protected by the agent. It would use the SiteMinder agent to authenticate the user ID, look up the user ID in the application's database, and return the user ID and password to the user's browser. A JavaScript function would then POST the user ID and password to the application's existing login page as if they typed it in themselves.
Are their concerns warranted? Why or why not?
Have you ever heard of anyone implementing a similar architecture?
Is their proposed solution good, bad, or ugly?
It does not look like it would work, because the agent manages not only the initial login, but subsequent calls to the application, i.e. authenticated session. The agent examines the cookie, validates it, etc. Your scenario does not describe how that would happen.
In our environment, all internet traffic goes through an Apache reverse proxy before hitting IIS. IIS is behind firewall. The Apache reverse proxy has the SM agent all it does is redirect the traffic to IIS. I suppose it would be feasible to do a similar setup with IIS acting as a reverse proxy.
BTW, tell your IT guy that his proposed shoestring and bubblegum login solution is a much bigger security concern than installing SiteMinder on IIS.
The apache reverse proxy solution will definitely work, but with SiteMinder r12.51, Secure Proxy Server is included, which is basically SiteMinder's version of a reverse proxy (plus a lot more).
SPS will let you configure a single server as a "gateway" for all of your applications that can't or won't install a SiteMinder agent. The web agent is embedded in SPS and a proprietary Java app does the heavy lifting. SPS also has a GUI which follows the look and feel of the r12 WAMUI, which makes configuring it very simple.
Secure Proxy Server also has a Federation Gateway feature, so you don't need to install the web agent option pack if you are doing SAML Federation. All of your fcc pages can also be served by the SPS, so you can reduce the number of webservers needed to support your SSO environment.
I want to implement SSO with SAML tokens in JBossAS.
The scenario is as follows.
I have 2 applications app1 and app2 running on 2 JBoss instances.
Login into app1 and enter username / password using form based auth.
Once login, click on the link that should be redirected to the app2 page.
This should use SSO with SAML tokens on JBossAS for authentication and authorization of users.
Can anyone let me know how to do this?
I just now found your question and noticed it is still not answered.
You can take a look at JBoss picketlink. Said page describes the federation support in JBoss 5+ and Tomcat 5.5+.
Supported protocols are SAML2, WS-Trust and Open ID.
Since SAML2 users Assertion after authentication, using pure SAML2 on both apps would require you to register both apps as Service Providers - I believe.
I did a workaround using JBoss/Tomcat SSO valves: My (Seam) app 1 uses SAML2 for authentication and my other apps simply reuses that Principal (username, roles) created in the first app. I believe this corresponds to your situation. Log in at app 1, security constraint in app2, no log in in app2.
I had to create a custom valve to achieve this
https://github.com/jensaug/jbossweb-customsso
/Jens