we are using PingFederate for SSO and is SP initiated. and Ping Federate will act like Idp. For application there are 2 webservers(for high availability
My questions is
1. can we provide two urls as default(In console as only one url can be set as default. in this case can we provide two comma seperated urls).
can load balancer url is provided for ACS url.
Thank you!
I think you want to publish the assertion consumer service URLs in SP metadata, as it is specific to the service provider.
You can have unique or same ACS endpoint for specific binding the SP supports and the endpoint has to understand response wrt to binding from IdP. Also ACS endpoints can be indexed and any one can be set as default in the metadata. Example:
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sts.contoso.com/adfs/ls/" index="0" isDefault="true" />
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sts.contoso.com/adfs/ls/" index="1" />
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sts.contoso.com/adfs/ls/" index="2" />
As long as IdP can reach the SP server from outside world, you could use load balancer URL.
As you have noted in the PingFederate Admin Console, you can specify multiple ACS URLs, however only one is a default URL. Each ACS URL is assigned an index number.
Using IdP-Initiated SSO, the default ACS URL will be used to send the SAML assertion if an ACSIdx query parameter is not supplied. This query parameter specifies which ACS URL is to be used. When the parameter is used, it will send the SAML assertion to the ACS URL associated to the index as shown in the PingFederate Admin Console.
Using SP-Initiated SSO, the ACS URL can be dynamic if the service provider application sends a signed AuthnRequest. Per the SAML specification SP-Initiated SSO can send a ACS URL that will be used by the Identity Provider (in this case the PingFederate IdP) to transmit the SAML assertion. Thus, the requesting server specifies how to return to itself granted the AuthnRequest is signed and trusted by the PingFederate IdP Server.
Related
I have configured IDP initiated SSO in PingFederate and it shows SSO Application Endpoint as: https://myserver/idp/startSSO.ping?PartnerSpId=sp_id
But when I download the metadata for this SP connection, in metadata the SSO Service Location is shown as: https://myserver/idp/SSO.saml2
Why does the metadata file show a different SSO URL?
These endpoints serve two different purposes.
The SSO Application Endpoint is a PingFederate proprietary endpoint that allows IdP-init SSO to be started. These proprietary endpoints are all suffixed with ".ping". This is the endpoint you could redirect users to to start the SSO flow to a given SP partner. More details:
https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FidpEndpoints.html
The SSO Service Location is a SAML 2.0 standard protocol endpoint for handling SAML request messages. These standard protocol endpoints are suffixed with the protocol name (in this case ".saml2"). This is the endpoint that your SP partner would send SAML requests to - that's why you find it in the SAML metadata file that you will could exchange with your partner. More details: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FviewingProtocolEndpoints.html
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.
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.
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.
We would like to implement such additional configuration for SSO in our organization:
Web application (with SpringSaml) --- WSO2 IS 5.0.0 --- SimpleSaml as IDP for WSO2 IS.
Our working SSO configuration is:
Other Services --> SimpleSaml
Almost all works OK. But if I login to WSO2 IS from my application and from other service I login to SimpleSaml and that other service send LogoutRequest to SimpleSaml, WSO2 IS receive LogoutRequest from SimpleSaml but don't answer and WSO2 IS produces error:
ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
I think, it is due to absence of sessionDataKey parameter in the logout request from SimpleSaml.
In IDP metadata for SimpleSaml I set a SingleLogoutService as
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://<server>:9443/commonauth"/>
Maybe it is not right URL. But I don't find SingleLogout URL for our configuration.
Could somebody help to resolve this problem or it is not possible to use WSO2 IS in such configuration?
Many thanks in advance!for
P.S. I'm very sorry for my english
What I understood from your comments that you have the setup of SimpleSamlPHP as your IDP which has connected to multiple SPs.Even the SimpleSamlPHP connected to WSO2 IS too.One of the SP send the Logout request to your SimpleSAMLPHP and the SimpleSAMLPHP pass the Logout request to WSO2 IS.
Let me describe how the logout request works on SP initiated Logout request.
LogoutRequest issued by SP to IDP
IDP determines authenticated SPs for given user session. If there are no SPs, other than the SP who sends logout request, the profile proceeds with step 5. Otherwise, steps 3 and 4 are repeated for each SP
LogoutRequest issued by IDP to SP
SP issues LogoutResponse to IDP
IDP issues LogoutResponse to SP who sends logout request.
The Logout URL you can make your custom URL where you want the user to redirect.
Refer the below Url to configure the external IDP to WSO2 IDP.
http://pushpalankajaya.blogspot.com/2014/09/leveraging-federation-capabilities-of.html
If you are using /samlsso end point in WSO2IS, It means that your are using SAML2 SSO. Therefore, you must send a proper logout request to the /samlsso end point. If you need to get more idea about SSO logout with SAML2 SSO, Please go through the below URL.
http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-works/