in Extended Metadata class, it says "Class contains additional information describing a SAML entity. Metadata can be used both for local entities
* (= the ones accessible as part of the deployed application using the SAML Extension) and remote entities (= the ones
* user can interact with like IDPs)."
I am not following what is local entity means. In my case, we use shibboleth idp and service provider as our spring web application deployed in tomcat.
In order to interact with your Shibboleth IDP you will need to define two entities (MetadataProviders). One will represent the Service Provider, i.e. the Application you wish to secure. This is the local entity. The other will represent the Shibboleth IDP, which is your remote entity.
What the code comment is saying is that the ExtendedMetadata class can be used for both local and remote entity configuration, as it contains configurations that are valid for both.
Related
I've created a microservice (using Spring boot) for landing page. User provides the credentials and upon successful login, he can see the dashboard. I've used RestTemplate in-order to traverse to other microservice from the dashboard. Below is the code snippets:
#Autowired
private RestTemplate restTemplate;
#GetMapping("/employeeCenter")
public String openEmployeeCenterApp() {
logger.info("Invoking EmployeeCenter micro-service");
return restTemplate.getForEntity("http://EMPLOYEE-SERVICE/empCenter/", String.class).getBody();
}
Which is working fine. But I would like to propagate the User's authentication (and authorization) to any other microservices; so that based on the user's privilage, I can show/hide stuffs. What would be the suitable way to do that?
There are many concerns here.
When a "landing page" service (let's call it "A") shows the dashboard for user with identity "Foo" and tries to contact an another service "B" which is an another process via Rest template, you should implement the identity propagation of "Foo", its not the job for the spring security. Spring security will help you in authentication / authorization of user "Foo" inside the service "A", but it has nothing to do with identity propagation.
After all, service "B" can be something not written with spring or java at all, or even some external system.
There are many approaches here depending on requirements that usually boil down to:
Rely on the fact that only landing page (service A) is your "gateway" to the outer world and hence on this service requires security
Protect all the services (like putting spring security or any other security component in each service)
Like "1" but differentiate between security gateway and landing page - have two microservices, so that gateway will be protected and will be "opened" to the end users but also to internal communication. The difference is that if you need to call service "B" from service "A" you can do it through the gateway and it will check the security
Another concern here is what exactly means the "act" of calling the service B from service A.
One thing is to tell "I'm user Foo (currently in a Service A) and I'm calling B as Foo.
Another thing is telling "I'm service A (that has its own identity) and I'm calling service B on behalf of user Foo".
All these question are in domain of security related architecture and many solutions can be adopted. If you have to do such an analysis (although its kind of out of scope for this question) make sure that you understand that performance implications of each approach:
- HTTP hops can be expensive
- DB hops (in case you have to turn to the database) are expensive
Apply caching wherever possible
Now, technically speaking, you should provide some Filter that will add Identity Headers taken from the Thread Local or similar solution if you run reactive stack.
So in the most simple situation you can put an identity object on some thread local and get it in the filter to add requests.
So that bottom line when you construct a request in a RestTemplate (that in turn relies on okHttp, Apache Http Client or whatever) it will have additional headers that will provide the identity information (and again its up to you to decide what exactly is an "identity" here).
The service "B" in turn should parse this object again in some kind of filter (ideally before it hits the rest controller if "B" is in spring as well) or even with spring security if you have it installed on Service B, and make its "protection decisions" based on that identity, then again, put it on thread local if B will query other services and so forth.
You can try using WebSecurityConfigurerAdapter and override the configuration of AuthenticationManagerBuilder bean which will let you set roles.
This article has a good example: https://www.journaldev.com/8748/spring-security-role-based-access-authorization-example
I'ld like to implement SSO using SAML 2.0 in my web applications. I have seen spring-security-saml and example of spring boot application. There are a couple of things I wanted to know after I went through the sample:
Is it possible to take Idp Url and certificates at run time and use spring saml to validate against that Idp? (So essentially I do not want to predefine any of the Idp related details and take an input from admin user to configure Idp)
Is metadata of Idp a necessary field or Is it possible that if IDP is not reachable directly from the SP then also it can just create a SAMLRequest to the Idp Url provided?
We are currently developing an application for a customer. The project has the restriction that we shall deliver only deployable WAR files. The customer provides the infrastructure and doesn't allow much deviation from it.
The application is developped with Spring Boot, Spring Security and SAML. The current version is a single monolithic WAR file.
At the moment, we are in the process of splitting this monolithic application in separate applications because of multiple reasons (maintainability, deployment, code quality, ...). Unfortunately we do not know yet how to implement authorization with these given restrictions:
Infrastructure constraints:
Applications will be deployed on JBoss EAP 7.0
A custom Identity Provider is provided by the customer
Communication with IdP has to be implemented with SAML 2.0
The custom IdP has the following restrictions:
Authentication is done through a proxy, which means only authenticated users arrive at the application
Only one SP metadata file can be provided, because it is linked to the user database. We want to share the same user database for all applications.
The SP metadata file can only provide one AssertionConsumerService-Location
The AssertionConsumerService-Location is statically defined in the metadata file and cannot be overriden in an AuthnRequest
Problem description:
Each application has to authorize itself with the IdP to receive roles and assertions. With the current (monolithic) deployment this is no problem as we require only a single AssertionConsumerService. With the new architecture, each application is able to redirect to the IdP, but the IdP can only redirect to the statically configured ACS. How can each application receive the AuthnResponse, when only a single ACS is possible?
Any ideas?
From SAML-standards point of view this could be achieved with an SAML IdP Proxy. Your apps, acting as the ServiceProviders only communicate with the IdP part of the IdP Proxy. The actual IdP only communiates with the SP apart of the IdP Proxy (so there is only a single ACS url).
I've deployed 1 webapplication (WAR) to Tomcat behind context root /myApp
The application is exposed to the public by means of 2 public HTTPS URLs:
Eg. https://a.this.that and https//b.this.that
Both these public requests arrive in that same application (/myApp).
Now I need this webapplication to support 2 SAML service providers.
Both will use the same IDP.
How should I configure Spring SAML in order for this application to support two SPs, one for the first URL, and one for the second ?
What ACS location URLs should I put in my service provider XML ?
Do I need multiple SP XML files and/or do I need to define extended service provider metadata to get this working ?
Do I need a spring saml multi-tenant setup to get this working and if so what is the relationship between the entityId and the URL ? Or can all this be achieved in a different way without a multi-tenant setup ?
Could somebody provide some sample xml metadata, spring saml config that demonstrates how the above could be achieved ?
Kr,
EDH
You'll need to generate SP metadata for each of the instances separately, and add it to the metadata manager. The URLs will be a.this.that in the first one, and b.this.that in the other. You also need to set entity alias to differentiate the two instances. See the manual for more details.
I am using WebSphere v8.5 and in the administration console, and the Security Settings in the Data Sources section allow me to set my mapping-configuration alias to either ClientContainer or WSLogin. What is the difference between these two settings?
I am able to connect and my project appears to work regardless of which setting I choose. Can someone please explain when is one setting chosen over the other?
Each one in the list is a Java Authentication and Authorization Service (JAAS) configuration, which in turn contains an IBM-implementation of the JAAS Login Module.
According to the reference page, Login configuration for Java Authentication and Authorization Service:
The WSLogin module defines a login configuration and the LoginModule implementation that can be used by applications in general.
The ClientContainer module defines a login configuration and the LoginModule implementation that is similar to the WSLogin module, but enforces the requirements of the WebSphere Application Server client container.
The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere Application Server user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system (EIS).
So for general use, you can use the WSLogin module. When you use a Java EE client, use the ClientContainer module. And when using Java 2 Connectors, use the DefaultPrincipalMapping module.
Check this link for a bit more information Configuration entry settings for Java Authentication and Authorization Service
In general, for any server resources like Datasources, queue connection factories etc, you should use DefaultPrincipalMapping.
ClientContainer alias is more dedicated to external applications running in the client container that will connect to WAS, and WSLogin is more appropriate for apps running on the server that would like to customize authentication process.