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
Related
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.
We are starting a project for SSO and using wso2 to do all SAML , OAuth and keep our Webapplications as service providers.
I have been through the online documentation but need some help .
When user tries to Access to any resource in our webapplication i would send user to wso2 to get Authenticated in case of OAuth /openid connect , how would i form this url ?
I have configured IDP and SP in WSO2 console, after authentication how does WSO2 give credentials of authenticated users to service provider , i see as per document or sample app , this should be SAML or any other sso protocols like oauth etc. documentation is not clear or any examples i can find
i want to redirect the user after OAuth or SAML with my own created Authn cookie , what is the provision for that .
any help would be appreciated
Yes, You can configure your application as service providers and wso2 IS as Identity provider.I guess, You can implement saml sso for your scenario and its simply documented here.There is another blog which describe the same configuration
You can download travelocity sample code and war file .Analysing the code you can get some idea about implementation.
By following above blogs, You can implement the complete SSO flow.
Q. > When user tries to Access to any resource in our webapplication i would send user to wso2 to get Authenticated in case of OAuth /openid connect , how would i form this url ?
Answer :
https://localhost:9443/oauth2/authorize?response_type=code&client_id=wCmphfs69oaN3JhqO3d9FFgsNCMa&scope=openid&redirect_uri=http://localhost:8080/Samplespapp/googleauth.jsp
client_id : is that if which we get on UI oof wso2 console after we finish configuring Service provider in my case i configured Inbound Authentication Configuration as OAuth open id .
redirect_uri is the url where we want to go after authentication , this should match callbackback url in View/Update application settings
Answer 2: I still dont see any valid reason why inbound authentication has to be sso protocol but this is how wso2 works , to put it in laymans term i have a client to connect to using SAML and Other OAuth . i opt for a SSO vendor who takes that headache from me to implement SSO protocols but i Still have to implement atleast one SSO protocol as after SSO handshake wso2 has to communicate userX with role as Admin to service provider app this is done again using SSO !!
ping federate makes it simple it makes an encrypted request header that had data in key value pair. may be i am not understanding but i dont like this inbound Authentication in SSO .
Q. 3.>i want to redirect the user after OAuth or SAML with my own created Authn cookie , what is the provision for that
documentation is poor in this area just some java classes but no end to end example , every one will point to travelocity .
I have two cross domain apps as service providers. These applications are with IdP (OpenAM) in federation trust. FSSO acomplishes over passive federation, SAML 2.0 protocol, Web Browser SSO Profile. This works fine.
What I have now as an issue is active federation as I see.
Use case :
Sign on App1 over IdP (web browser profile).
Invoke from App1 , App2's web service (SOAP) and send
something
App2 web service should process incoming request without authentication (as these two apps are in federation trust)
As I understand, it should be used SOAP binding most probably in combination with artifact or I am looking wrong ?
What will be the use case ?
Should I send from app1 within SOAP - SAML message completely ?
Or to send to App2 service artifact id and then service will resolve artifact from IdP ?
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