We are working on the development of micro services for our domain.
We have a requirement to secure the micro services using SAML.
I read through the SAML docs and see that there would an Identity provider to which we have register our application (SP) and also we should connect to IdP for authentication. I understand that we need to establish a circle of trust or federation between them.
I tried using the Spring Security SAML extension and SSOCircle.com as IdP for authentication using the sample application provided. I was able to successfully authenticate accordingly.
My question is, in a micro services architecture, we have multiple services. Since it is not a monolithic we cannot just add one service as a SP to the IdP.
That means every micro service I have say, employee, department,sales etc should also be added as a separate SP application in IdP.
I am not sure if that makes sense or actually possible to do so.
If anyone has worked on a similar architecture/development can you please provide your thoughts on the best way to approach the security of micro services from the point of authentication.
Thanks,
bstechie
Two ways to do this:
As you said, configure each micro-service as SP and each SP talk to IdP for SAML authentication.
This is suitable, if each micro-service has different set of users, groups and roles than others.
There could be multiple SPs, which admin need to maintain.
Consolidate and configure all micro-services to single SP at your domain (may be use Reverse Proxy Web-Server or Access Manager) and that single SP talk to IdP for SAML authentication.
This is suitable, if all micro-service has same set of users, groups and roles.
There could be only single SP that admin need to maintain.
Related
We are in process of building a series of apps that will run offline or in very austere environments. We'll also be integrating with other 3rd party apps. Many of these will require logins so we're attempting to use SAML to handle login between them.
I found saml2-js:
https://github.com/Clever/saml2
And it seemed like a great starting point for both the SAML Service Provider and Identity Provider - but diving in I now see it does not implement the Identity Provider at all.
I already have a basic SAML Service Provider setup, but we need an Identity Provider that can run offline. Are there any Node or GoLang Identity Provider libraries we can use to implement this? If not, another recommendation?
Passport is the usual Node option but that's client side only.
There are a number of IDP's you can use e.g.:
Free: simpleSAMLphp / Shibboleth / identityserver4
Cloud: Auth0 / Okta / Azure AD
On-premises: ADFS
I am evaluating different protocols and software packages for my SSO project and I was thinking about the pros and cons of making an SSO system with SAML and one with something like CAS or Shibboleth. I couldn't really find any reason why I should choose SAML over Shibboleth or CAS since these two SSO solutions not only support SAML, but also many more functions that I otherwise have to implement.
Any ideas?
The important thing that Shibboleth offers is that it has 2 servers, SP (Service Provider) and IDP (Identity Provider). The SP server communicate with any IDP sever over the network, simply and only with configurations you can get an SSO working perfectly and it respects the SAML norms.
For example, you have a site that can be authenticated from multiple companies credentials, each company has it's own identity system, you don't have to deal with how they connect to their systems (CAS, shibboleth idp ...) but only how to protect your data using SAML2, this is done by sharing metadatas over this federation.
We are trying to federate our application, so that our customers can gain access to our application using their respective corporate identities.
Well, I understand the mechanism of federation process, I’ve been able to setting up ADFS and I’ve modified the code of our application for accepting claims into my lab environment and all work fine.
In the next weeks I’m going to build a federation trust between ADFS and our customer’s product (Ping Identity) and I need your help to understand what kind of information I’ll have to exchange with customer’s IT department to complete that step.
I’ve never been experience with Ping Identity products.
Appreciate any help.
Many Thanks
I am going to make a couple of assumptions about your application, mainly that it is .NET application hosted on IIS. This type of application integrates Windows Identity Foundation (WIF) using tags in the web.config and then reads the authenticated users identity information via the Claims Identity object passed to your application. In this case your application is referred to as the Service Provider (SP).
If your customer is using PingFederate, the integration is straightforward in that a WS-Federation SP Connection would be configured on their server referred to as the Identity Provider (IdP). If your customer is using PingOne, then the integration will be tricky.
The information to exchange for PingFederate is driven by the configuration in the configuration in web.config. You need to configure the thumbprint which is based on the digital signing certificate of the WS-Federation response containing the SAMLv1.1 token. Your customer will be able to provide the thumbprint value. You will also need to configure the federated authentication URL, issuer, and realm, which is the information about PingFederate IdP server. The issuer is the URL for your SP application to redirect to the PingFederate IdP server, along with the realm which equates to the PingFederate SP Connection. Be sure that you configure the audienceUris to be the same value as the realm. The PingFederate administrator will need to know your Service URL endpoint which is your SP application endpoint to receive the WS-Federation response with the SAMLv1.1 token.
I installed PingFederate on an AWS EC2 running Windows_Server-2008-R2_SP1-English-64Bit-Base-2014.04.09. I have a Java application that is using Spring Security for authentication.
I have read about how with PingFederate, I can set up an Identity Provider(IdP) and a Service Provider(SP). I have gathered that the IdP would be the Application User providing login credentials(the Identity) and passing this to the SP which has the Target Application apart of the SP in this diagram on this page here:
http://documentation.pingidentity.com/display/PF66/Service+Providers+and+Identity+Providers
This image also shows the Federated Identity Software on both sides of the IdP and the SP.
I have created an IdP and SP with my local PingFederate server just to see what the configuration options are and I am confused on which parts of this I actually need to be able to have a SSO for my Spring Security application.
My questions are:
Do I need an IdP and SP to implement that I am trying to do.
Right now our usernames and passwords are stored in a SQL Server, would I leverage this for PingFederate to use to authenticate the users?
Should I even be using Spring Security SAML for this or would another route be more appropriate?
Thanks for any help, I have reached out to PingFederate but my Regional Solutions Architect happens to be out until Friday.
I also apologize if I am completely off in my thinking, I am trying to wrap my mind around what is needed.
Presuming your goal is to establish federation between Ping and your application (in order to e.g. externalize authentication or enable single sign-on), your thinking is correct.
The Ping Federate serves as an Identity Provider (IDP) and you can configure it to connect to your SQL server, so that it can authenticate your existing users from there. IDP communicates with other applications which are called Service Providers (SP).
In order to connect to Ping your application therefore needs to be able to act as a SAML 2.0 Service Provider and using Spring SAML is a very good way to enable it to do so.
The typical flow of data between SP and IDP for single sign-on is similar to:
User accesses SP application which requires authentication
SP creates an AuthenticationRequest and sends it to IDP (using redirect in user's browser)
IDP processes the request and authenticates the user
IDP responds back to SP with an AuthenticationResponse message
SP processes the response and creates a session for the user based on the included data
There is an assumption being made that you need SAML between your Spring app and PingFederate. That is not true depending on how it is deployed and if you (see Andy K follow-up questions). You should check out the OpenToken Integration Kit for Java or perhaps the ReferenceID Int Kit from Ping as a possible solution. Much simpler to integrate than trying to hack together another SAML solution that may not be needed. However, I would recommend talking to your RSA who can give you the best approach for your scenario.
I have a requirement for cross domain sso. So, i chose OpenAM with SAML. I have two applications hosted in different servers and host for which i need to implement SSO.
Now i read about OpenAM with SAML but could get the core idea about the setup. LDAP is used as user data store.
Now i have something in mind and want to verify if it meets my requirement.
Since i have two applications(AppA and AppB) in need of SSO implementation. I need two OpenAM configured as service provider? and should be deployed in different tomcat containers? Should the each service providers be deployed in AppA and AppB?
I need another separate tomcat container for identity provider OpenAM?
The sp should be registered to idp and idp should be registered to sp within same Circle of trust?
Do i have to do anything else? Again do i have to configure separate LDAP for each idp and sp ? Anyway, what can be the ideal setup in my case?
You need one IdP, your apps have to implement the SP. If your apps are Java based you could leverage OpenAM's Fedlet or use Spring Security SAML extension (works like a charm).
There's also a PHP SAML SP and even an Apache http server SAML module ...
Or you could use OpenIG as a reverse-proxy (but it's a java web app) which also implements a SAML SP.
-Bernhard
One more possible solution in which you can use OpenAM out of the box is by using OpenAM identity federation:
Use the standard OpenAM Identity federation setup (with IDP and SP) as explained in this post: http://fczaja.blogspot.com/2012/06/idp-initiated-sso-and-identity.html
You will need to have an IDP for AppA and SP for AppB or vice versa. IDP will be connected to your user store.
On SP side create a dummy user store using something like OpenDS.
Import all the users from IDP to SP (using a scheduled daily batch job)
Implement auto federation based on one or more of the user attributes.
Use OpenAM authorization features on SP side to give access to SP side App