I have implemented the supporting of SAML SSO to have my application act as the Service Provider using Spring Security SAML Extension. I was able to integrate my SP with different IDPs. So for example I have HostA,HostB, and HostC, all these have different instances of my application. I had an SP metadata file specified for each host and set the AssertionConsumerServiceURL with the URL of that host( EX:https:HostA.com/myapp/saml/sso ). I added each metadata file to the IDP and tested all of them and it is working fine.
However, my project also supports High Availability by having an IBM HTTP Server configured for load balancing. So in this case the HTTP Server will configure the hosts(A,B,C) to be the hosts used for load balancing, the user will access the my application using the URL of the HTTP server: https:httpserver.com/myapp/
If I defined one SP metadata file and had the URL of the HTTP Server specified in the AssertionConsumerServiceURL( https://httpserver.com/saml/sso ) and changed my implementation to accept assertions targeted to my HTTP Server, what will be the outcome of this scenario:
User accesses the HTTPServer which dispatched the user to HostA(behind the scenes)
My SP application in HostA sends a request to the IDP for authentication.
The IDP sends back the response to my httpserver as: https://httpserver.com/saml/sso .
Will the HTTP Server redirect to HostA, to have it like this: https://HostA.com/saml/sso
Thanks.
When deploying same instance of application in a clustered mode behind a load balancer you need to instruct the back-end applications about the public URL on the HTTP server (https://httpserver.com/myapp/) which they are deployed behind. You can do this using the SAMLContextProviderLB (see more in the manual). But you seem to have already successfully performed this step.
Once your HTTP Server receives a request, it will forward it to one of your hosts to URL e.g. https://HostA.com/saml/sso and usually will also provide the original URL as an HTTP header. The SAMLContextProviderLB will make the SP application think that the real URL was https://httpserver.com/saml/sso which will make it pass all the SAML security checks related to destination URL.
As the back-end applications store state in their HttpSessions make sure to do one of the following:
enable sticky session on the HTTP server (so that related requests are always directed to the same server
make sure to replicate HTTP session across your cluster
disable checking of response ID by including bean EmptyStorageFactory in your Spring configuration (this option also makes Single Logout unavailable)
Related
We're developing a web application (SPA) consisting of the following parts:
NextJS container
Django backend for user management
Data API (FastAPI) protected with API keys, for which we also provide 3rd party access
The NextJS container uses an API key to access the data API. We don't want to expose the API key to the client (browser), so the browser sends the API requests to the NextJS container, which then relays it to the data API, see here. This seems secure, but is more complicated and slower than sending requests from the browser to the data API directly.
I'm wondering if it's possible to whitelist the web application in the data API, so that the client (browser) can call the data API directly without API key, but 3rd parties can't. FastAPI provides a TrustedHostMiddleware, but it's insecure because it's possible to spoof the host header. It has been suggested to whitelist IPs instead, but we don't have a dedicated IP for our web application. I looked into using the referer header, but it's not available in the FastAPI request object for some reason (I suspect some config problem in our hosting). Also, the referer header could be spoofed as well.
Is there even a safe way to whitelist our web application for data API access, or do we need to relay the request via NextJS container and use an API key?
Is there even a safe way to whitelist our web application for data API
access,
No, you need in all case an Authentication mechanism, something before the backend that check if the client is an authorize client.
The simplest pattern is using the NextJS container as the proxy. Proxy that have an api-key to call the backend ( what you are currently doing ).
There is many way to implement a secured proxy for a backend, but this authentication logic should not be inside the backend but in a separate service ( like envoy , nginx ... )
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
I have a situation where I need to authenticate my application users with SAML2.0. SAML server is hosted at a public domain while our application runs in local intranet.
I wonder, if SAML would support redirecting my users back to the local application (local IP) after authentication.
This is by default or is there any special configuration need to be done in SAML server side?
If the application is being accessed from the local intranet, it will definitely work. There won't be any additional configuration required for that. The reason is simple - SAML uses HTTP Redirects and Form-Post to pass SAML tokens. So if the two applications (IdP and SP) are accessible, it will work.
I have an ADFS server on Azure (available publicly) and the SP is in my local development environment (accessible only on my laptop). It works.
SAML protocol provides the 'RelayState' request parameter for certain bindings. E.g. have a a loot at http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
This allows to specify a target URL for your application acting as SAML SP.
I have a web application (gwt) that is running on a tomcat application server. This web application consumes several web services (login, application data transfer, queries, etc.). The web service client on the tomcat is implemented as apache axis2 web service client.
For user log on I provide a form in the web application with username and password. This data are transmitted via web service to authenticate the user.
It is planned to change the hole authentication mechanism to client certificated based authentication. The authentication still should be done on the web service provider side.
So my system has three relevant components: the web client, the tomcat application server and the web service provider.
Every user of the application has its own private client certificate (PKI Token, X.509- Auth-Cert). When the user connects to the web application his certificate is requested.
How can I forward the client certificates for use in the web services? (The tomcat will not be responsible for authentication).
1.) Is there a way to intercept the request and extract the client certificates before authentication error occurred?
I found some information about Servlet Filters what sounds really good, but I’m not sure where to implement it to intercept the certificates before they are verified against tomcats keystore.
2.) If it is possible, how can I pass after the client certificate to the web service?
Thank you for reading
No, not really. The real piece used in authentication is the private key associated with the certificate, not just the certificate itself. And, typically, you have no way of retrieving that from the web client. Therefore, you cannot really pass-through the credentials you receive from a web client on to the web service client. The certificate itself is readily available, but is useless for authentication without the corresponding private key.
I am completely new to SiteMinder and SSO in general. I poked around on SO and CA's web site all afternoon for a basic example and can't find one. I don't care about setting up or programming SM or anything like that. All of that is already done by someone else. I just want to adapt my JS web app to use SM for authentication.
I get that SM will add a HTTP header with a key such as SM_USER that will tell me who the user is. What I don't get is -- what prevents anyone from adding this header themselves and bypassing SM entirely? What do I have to put in my server-side code to verify that the SM_USER really came from SM? I suppose secure cookies are involved...
The SM Web Agent installed on the Web Server is designed to intercept all traffic and checks to see if the resource request is...
Protected by SiteMinder
If the User has a valid SMSESSION (i.e. is Authenticated)
If 1 and 2 are true, then the WA checks the Siteminder Policy Server to see if the user is Authorized to access the requested resource.
To ensure that you don't have HTTP Header injections of user info, the SiteMinder WebAgent will rewrite all the SiteMinder specific HTTP Header information. Essentially, this means you can "trust" the SM_ info the WebAgent is presenting about the user since it is created by the Web Agent on the server and not part of the incoming request.
Because all traffic should pass through Siteminder Web Agent so even if the user sets this header it will be overwritten/removed
All Siteminder architectures do indeed make the assumption that the application just has to trust the "SM_" headers.
In practice, this may not be sufficient depending on the architecture of your application.
Basically, you have 3 cases:
The Web Agent is installed on the web server where your application runs (typical case for Apache/PHP applications): as stated above, you can trust the headers as no requests can reach your application without being filtered by the web agent.
The Web Agent is installed on a different web server than the one where your application runs, but on the same machine (typical case: SM Agent installed on an Apache front-end serving a JEE Application Server): you must ensure that no requests can directly reach your application server. Either you bind your application server to the loopback interface or you filter the ports on the server.
The Web Agent runs on a reverse proxy in front of your application. Same remark. The only solution here is to implement an IP filter on your application to only allow requests that come from your reverse proxy.
SiteMinder r12.52 contains a new functionality named Enhanced Session Assurance with DeviceDNA™. DeviceDNA can be used to ensure that the SiteMinder Session Cookie has not been tampered with. If the Session is replayed on a different machine, or from another brower instance on the same machine, DeviceDNA will catch this and block the request.
Click here to view a webcast discussing new features in CA SiteMinder r12.52
Typical enterprise architecture will be Webserver (Siteminder Agent) + AppServer (Applications)
Say IP filtering is not enabled, and webs requests are allowed directly to AppServer, bypassing webserver and the sso-agent.
If applications have to implement a solution to assert the request headers / cookies are not tampered / injected, do we have any solution simillar to the following?
Send the SM_USERID encrypted in a seperate cookie or encrypted (Sym/Asym) along with SMSESSION id
Application will use the key to decrypt the SMSESSION or SM_USERID to retrive the user id, session expiry status and any other addtional details and authorization details if applicable.
Application now trusts the user_id and do authentication