I am implementing a typical classical SSO between 2 websites, on 2 different domains. One website (let's call it site1) is developed and hosted by a partner, the second website (let's call it site2) is developed and hosted by me.
I use the partner ADFS as an Idp.
I installed and configured Shibboleth SP3 to manage the authentication on site2: when I try to access site2, I am correctly redirected to the ADFS and it works.
My concern is, the end-user will authenticate to site1 first, then along the way access site2, and we don't want him to authenticate again.
I have few questions about this, how I don't know how to proceed:
- do I need the same instance of Shibboleth SP3 to manage authentication on both sites, to manage the cookie / headers, or can I use different instances (in that case, I would use Shibboleth for site2, and the partner will use another SP for site1)
- how to manage the redirection from site1 to site2 ? Can it be a request.redirect? Should site1 send a post or get request, with specific parameters?
Thanks !
If the partner is hosting site1, they should be running Shibboleth on that instance, and integrate with the IdP the same as you on your instance running site2.
The whole purpose of SSO is that they don't need to re-auth. i.e. User visits site1, redirected to login on ADFS, auth (user is picking up IdP session), redirected back to site1 which validates the auth token (SAML assertion) and shows them the content.
Now, when they are pushed to site2 (by whatever means), site2 fires off the authnrequest to the ADFS server as a redirect with the user, but this time the user already has the ADFS session, so the ADFS server just issues the SAMLResponse. They don't make the user log back in.
This is only because both SPs are integrated with the same IdP.
You can redirect the users around however they want in this instance... but it means running instances of Shibboleth on both web servers. If you really wanted to only use one Shibboleth instance, you could create a SAML broker, where one webserver brokers the SAML assertion on behalf of another, but that's kind of silly. Easier to just run to Shib installs when it's two disparate servers.
If both sites live on the same server, you can do the same thing, basically... each site is a separate host on on the webserver, and you just need to configure each site (one as a default, and another as an Application Override) though you probably don't even have to go that far TBH. You'd only need to have separate ApplicationOverrides if you wish to, say, integrate site 1 with IdP_A and IdP_B, but site 2 with IdP_A and IdP_C. See: https://wiki.library.ucsf.edu/display/IAM/Steps+to+configure+multiple+context+in+Shib+SP
Related
I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.
to make long story short. Customer has both SP (referred as SP1) and an IDP. We are integrating our application (referred as SP2) to serve a protected resource. The resource will be available after the principal identity has been verified at IDP - typical SSO service. The following scenario would like this:
1. Pricipal enters SP1.
2. No security context has been created for the user yet, so he logs to IDP.
3. After a sucessful login, the user tries to access a resource on SP2 from SP1.
4. Request comes to SP2, which needs to verify principal identity.
5. SP2 tries to log in to IDP (HTTP Redirect Binding).
6. IDP verifies there is a security context and does not offer a login form but strikes back with assertion.
7. Resource is served.
Question 1 - For testing I am using shibboleth IDP and oiosaml java libraries for SP2. How does IDP (step 6) verify that use is logged in? Is it checked via presence of some cookie? Is it vendor specific check?
Question 2 - SP2 IP is not external so we would need to create a tunnel between SP1 and SP2 and between SP1 and SP2. Is there any standard scenario to verify principal authority without hitting IDP (step 5)?
As far as I know it is not specified how the IDP keeps track of security contexts. But I have never seen anything else than cookies.
I'm not sure you need the tunnel. There will not be any direct communication between SP1 and SP2 only between the SPs and IDP. And provided you use POST binding to deliver the SAML assertion there will not be a direct communication there either. In this case all communication would go over the browser.
This means that the browser must be able to connect to all of the nodes but the nodes does not need connectivity to eachother. Provided you use POST binding and not Artifact Binding.
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.
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 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