There is an existing mechanism to log into a website. Now, external / remote SAML IDP is being added to facilitate SSO. The website uses other micro-services and components that provide data and functionality to the website.
Is there a way to have an existing mechanism of local identity username password credentials to continue to co-exist as an alternate strategy for authentication alongside remote IDP SSO while keeping rest of the services handling authorization in a semantic way (using a saml token)?
P.S. I looked at the options to implement existing auth mechanism as saml IDP, but building it seems complex even with the likes of shibboleth or openSAML libraries.
P.P.S. I haven't looked at possibility of reimplementing existing auth mechanism with openId connect to co-exist with remote saml idps.
Sure: one can provide a landing page to the user that gives a choice between using a local account or an account at a remote IDP.
Related
I'm trying to create a SAML IDP for the system I built. Probably I'm getting confused with concepts. My problem is as follows:
This system was built in SymfonyPHP which authentication is made by OAuth token. Nothing so special, the username and password are passed to the /auth endpoint and the request returns the token if the credentials are valid. It's working fine.
Now I have to integrate this credentials to a client system. Once the user is logged to my system, so it should be on the client side (like the "login with Google button). I've been searching and realized I should use SAML for that.
I installed the SimpleSAMLPHP and I'm trying to understand how to set it up as my IDP. Once it's made, I can create SPs for my clients systems.
Question: how to make the SimpleSAML use my existing service for authentication? Which module should I use?
With SimpleSAMLPHP acting as an IdP, you want to have a look at authentication modules. The latter is a component that encapsulates the mechanics of signing into the identity provider. For example, if you were trying to sign in to the IdP with your Facebook account, SimpleSAMLPHP ships a FB authentication module that does this for you.
If your existing service can be supported by one of the SimpleSAMLPHP modules, then you're all set. Else, you need to develop your own module.
I've just configured Shibboleth IdP3.2 with my web application that authenticates the users against an LDAP server at the backend.
I could test this authentication process at the local machine. But, while deploying the code on CI server, I realized that the authentication process could not be completed successfully.
The reason behind this failure is that the Service Provider (SP) cannot access the (IdP). From our initial investigation, We chose SAML as the authentication protocol over other protocols like CAS because it did not need a back channel communication. As long as the user has access to both SP and IdP,the authentication process would still work.(SP and IdP need not interact with each other)
On testing we found that the attribute resolution is successful, but the subsequent artifact resolution is failing. In artifact resolution, IdP directly contacts the SP and expects a response. SP cannot send a response to IdP as it is inaccessible. Hence, the authentication fails. (Tomcat logs show: unknownHostException)
Some SAML flows in Web Browser SSO do not require direct communication between SP and IdP as seen from flow diagram in this link.
Does Shibboleth IdP make provisions for such implementations? Is there a work around for implementing Shibboleth IdP without any back channel communication?
SOLUTION:
As Stefan mentioned, there are alternative bindings like HTTP-Redirect and HTTP-POST that do not use back channel communication. You can read more about these bindings here
I changed the SP metadata to make HTTP-POST as the default binding, referring this link.
I did not have to make any changes to Shibboleth IdP configuration as these alternative bindings were already being supported, as substantiated by the metadata file.
According to this documentation, you can set the outgoingBindings attribute to set the preferred binding to use.
I would also recommend removing the HTTP-Artifact binding from the SP metadata.
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.
We are building a SaaS application (enterprise oriented).
We have to be able to log-in the users against the saml2 IdP of their company with SSO functionality (so multi-tenant context)
We prefer to manage it in a isolated component and so not directly on the application it self.
We think to use a kind of "proxy".
We have two questions :
- Does WSO2 IS is able to act as proxy, delegating the authentication to an extern IdP ?
- Our SaaS application will be offered via UI relying on REST ful services, so we need to manage SSO
also with the services, so for example :
. The user comes on the UI without any log-in before
. The company IDP login-page is shown for authentication
. Once logged , the UI will perform some calls to REST service and we need to secure those service call, to be sure
the user is allowed to call this service
How to manage it ?
Does the "proxy" API can act also as "proxy services" in order to call the extern IDP API ?
Tks
Nicolas.
If i got your question correctly, There is an existing IDP in "foo" company. In "bar" domain you have applications. You are not going to integrate application directly with IDP in "foo". And you are wishing to install an another IDP in "bar" domain where this "bar" domain IDP can talks to existing IDP in "foo" domain. Yes. WSO2IS can be used to implement such use case. It has "Authentication Framework" for SAML2 SSO logon... Let me explain it bit. When user is directed to WSO2IS SAML2 IDP, user can be authenticated by verifying user/password which is the default behavior. (default authenticator that is picked by "Authentication Framework"). But there can be any other authenticators such as SAML2 SSO (where WSO2IS can call to another SAML2 IDP and authenticate the user), OpenID and so on. I guess, same scenario has been discussed here. I found blog on implementing this.
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