We are acting as service provider (supporting SAML2.0) and we are working on a proposal to federate with a new federation whose IDP is ADFS2.0. We are currently supporting several other Federations that are currently using OKTA as their IDP.
We expect the IDP to post SAML assertion either through (SP initiated or IDP initiated). If ADFS2.0 is acting as IDP, will the SAML assertion will be similar to OKTA or will it be different? (I heard that the SAML assertion from ADFS2.0 will be compressed in addition to Base64 encoding while from OKTA it is only base64 encoded.)
You can expect both OKTA and ADFS to support the SAML2 standard.
If you are using the HTTP Redirect binding the xml is deflated+Base64-encoded. If you are using the HTTP POST binding the xml is only Base64-encoded. For receiving SAML2 assertions you shouldn't use the HTTP Redirect binding due to data length restrictions. So if you have a working implementation for OKTA it should work for ADFS too.
Related
We are using SAML 2.0 with ADFS hosted on Windows Server 2016. SSO is working. Users can successfully log into the ADFS identity provider and are redirected to the relying party and the SAML token is decrypted, assertions are read, and the user is successfully logged in. So far, so good.
SLO with ADFS and SAML 2.0 is not as clear. The OASIS specification (https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) includes the following guidance on creating SAML 2.0 LogoutRequest. On page 33, the process for issuing the LogoutRequest is described as follows:
LogoutRequest issued by Session Participant to Identity Provider
In step 1, the session participant initiates single logout and terminates a principal's session(s) by
sending a LogoutRequest message to the identity provider from whom it received the
corresponding authentication assertion. The request may be sent directly to the identity provider
or sent indirectly through the user agent.
How is this step applied to ADFS? Specifically:
What endpoint on ADFS should the LogoutRequest be sent to?
If it is a POST request should the XML be submitted in the body? If not, how should it be packaged?
The majority of documentation we have found online that discusses SLO on ADFS uses WS-Federation rather than SAML 2.0.
ADFS's endpoint for SAML SLO is https://[your-adfs]/adfs/ls/
And yep, usually it's a POST containing the <samlp:LogoutRequest ... in its body.
See this answer for much more details.
I'm implementing an SSO authentication flow using SAML for a web server running tomcat. Everything is working ok when using POST or Redirect bindings, but from what I've read to support the SAML authentication in front of a REST API I need to also configure and use an ECP profile.
First correct me if I'm wrong but the ECP flow should be like this:
Client accesses the SP REST API
Client knows he needs to authenticate so he sets up the required ECP headers (Accept: application/vnd.paos+xml and PAOS: urn:liberty:paos:2003-08;urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp)
SP sees client is not authenticated and returns a SOAP Envelop containing PAOS Request.
The client is responsible to send this to the appropriate IdP on its ECP consumer service.
The IdP challenges the client for authentication
The IdP returns a response in the form of another SOAP Envelop, containing the saml Response in its body
The client must send this response to SP's ECP/SOAP assertion consumer service
The problem is all of this works until step 6. On this step I have the problem, that the Body of the response envelop contains a Destination attribute, which points to the POST assertion consumer service of the SP. This destination attribute is set by keycloak and mismatches the actual ECP service that I want to send the response to. The SAML library we are using is opensaml and it checks the request URI against this Destination attribute and if they do not match it throws an exception org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint.
I understand why this exception is thrown, but cannot understand how I can configure Keycloak with the ECP/SOAP service of the SP. In Keycloak's admin console I can only configure the URLs for SSO POST/Redirect and SLO POST/Redirect, but nothing about ECP.
I'm currently in the process of configuring another IdP, but I would really like to make sure that Keycloak can also be a supported server for our solution.
Can't you just read the paos:Request responseConsumerURL and post the idp response to that url?
At least, that's how I managed to do it.
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 am creating a java application to implement SSO (SAML) using ADFS. I am not sure if SAML can be done using ADFS alone. While installing ADFS, I noticed that it required configurations of relying party and claim providers trusts (which are basically the SP and IP, right?). I am confused as to whether to have SP and IP in the java application, or just leave it to the ADFS to handle.
Any help would be greatly appreciated. Thanks!
Your Java application needs a SAML stack and becomes the SP.
Refer: SAML : SAML connectivity / toolkit for some ideas if you don't have one.
ADFS (which handles SAML 2.0) can then function as the IDP.
You will also have to configure the claims in ADFS - which correspond to the SAML assertions.
Your Java application will be a Service Provider (SP) that receives identity from an Identity Provider (IdP) server. In the use case you have outlined, ADFS will be the IdP Server. within your application you will need to integrate a library (e.g. SAML stack) to process the SAML assertion. SAML requires configuration on both sides of the interface. There are a few open source options such as OpenSAML. Depending on your organization, you may want to look at a vendor provided solution as well for long term support.
I am very confused about my current ADFS setup. I have an identity provider that issues a SAML 2.0 token to ADFS 2.0 in an IDP-Initiated scenario. ADFS translates the token into WS-Federation, and forwards it on to a claims aware (WIF) web application. The web application, however doesn't recognize the user has having authenticated and redirects back to Home Realm discovery. I've used SAML Tracer in Firefox and I can see the SAML assertions going in and the WS-Federation claims in the parameters being sent to the web application. Is there a step I am missing? I set up custom claim rules to translate the SAML assertion into a WS-Federation claim (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name) If I switch the SP application to a SAML 2 web app, then everything works fine.
So after comparing the headers of an IDP initiated request and an SP initiated request, I noticed a difference. The IDP initiated request was missing the wctx parameter. Once I included this in my relaystate, the WIF RP app worked fine.
wctx=rm%3D0%26id%3Dpassive%26ru%3D%252FMyDesiredStartPage.aspx