We have a CRM Dynamics 2016 onpremise (IFD configured), we access to the CRM from a Cordova mobile application via SOAP authentication and consume the service "Organization.svc" to get or set Data: everything works fine until now.
After adding a Web Application Proxy, the call to ADFS for the token still working, and returns a valid token. However, the second step of consuming the service "Organization.svc" is blocked : the Web Application Proxy redirects the call to the ADFS login page, which is of course not what I want.
I think the root of the problem is in the fact that the proxy cannot 'read' the SAML token I'm sending in my HTTPRequest.
Did anyone have an idea how to resolve that ?
Could you maybe inspect with Fiddler if the proxy is forwarding the required authentication cookies / headers ? I presume these are ignored by the proxy and ADFS sees the second request as not authenticated.
Related
I have next components:
RP-1 (connected by Ws-Fed, WIF)
RP-2 (connected by SAML, Federation Provider, actially it is another ADFS)
MY-ADFS (ADFS Server 2019 as primary STS)
MY-IP (separate Identity Provider web service, Identity Server 4)
Thus, when I make a sing-out request from RP-1(Ws-Fed), a simple Ws-Fed Logout is formed a request to ADFS:
GET https:/MY-ADFS/adfs/ls/
wtrealm: https://RP-1.com/
wa: wsignout1.0
wreply: https://RP-1.com/logout/
Next ADFS makes redirect to IP:
GET https://MY-IP/WsFederation
wa: wsignout1.0
wreply: https://MY-ADFS/adfs/ls/?redirectContextId=2dd581d2-6e02-4476-915b-a581e3c855d4
thus the user clears the session from ADFS and from IP. - as expected.
However, if before the logout, the transition to SAML RP was made and the SAML session became active, then upon exiting ADFS gives an error:
MSIS7055: Not all SAML session participants logged out properly. It is
recommended to close your browser.
To fix it, I configured the logout endpoint (URL) in the SAML relying party trust as:
https:/RP-2/adfs/ls/?wa=wsignout1.0
With POST binding. After these changes, the error disappeared. But now ADFS no longer does make Logout redirec to to IP, but instead it does a SAML Logout redirect to RP-2:
POST https://RP-2/adfs/ls/?wa=wsignout1.0
SAMLRequest: PHNhbWxwOkxvZ291dFJl
And as a result, Instead of switching to IP, I remain on the RP-2(ADFS also) page where it is written that the exit was successful. However, the user still has an active session (cookies) on the IP side.
Several questions here:
It is not clear why ADFS changes the chain of calls with the SAML active session.
It is not clear how to exclude SAML Logout redirects, or force ADFS to make Logout to IP also.
You will have to add the logout URL in the IP (Identity provider) side as well to ensure that the SAML token generated by signing out from the SaaS application through ADFS is forwarded to the Identity provider and is updated for logout at IP authorization provider end. So that, the cookie on the browser will be updated and sign out will be processed smoothly.
Please find the below probable steps to update the logout URL at the Identity Provider end: -
Open the authentication provider workspace.
Find the logout URL.
Update the URL to the ‘https://RP-2/adfs/ls/?wa=wsignout1.0’ same as that configured in ADFS Server.
Save your changes.
And as for your first query why ADFS changes the chain of calls with SAML active session, it is because the cookies and cache must be removed from the system for successful logout request, thus the logout time as recorded when signing out is updated at the SaaS app end and thus, it is recommended to close the browser let it update in the system also.
Thus, recommend you open both the RP trust apps in different browser windows as both are configured for different token providers.
Please refer the below thread for more information: -
How do you handle the logout process for applications federated with ADFS?
Thanking you,
We have a microservice based environment running our own authentication server that will produce JWT tokens using the /oauth/token endpoint but this server does not provide a web login page.
For our front end application we have tried the oauth2Login setups but they all want to try and redirect the browser to the authentication server, authenticate and then redirect back to the application. Likewise oauth2Client setups add an AuthenticationProvider but that will only authenticate a OAuth2AuthorizationCodeAuthenticationToken but the user login request will generate a UsernamePasswordAuthenticationToken so oauth2Client provider never gets evaluated.
We were looking for something similar to the ldap authentication providers in that the username and password is collected locally and sent to the authorisation server. While we can write our own custom AuthencationProvider which accepts the UsernamePasswordAuthenticationToken, communicates with the oauth server and return the generated JWT. We were hoping there was something pre-existing that was part of the current spring-boot framework. If our understanding is correct then the oauth2Client setup is what we are after but can't work out how to enable the initial authentication.
We are using spring boot 2.2.5.
I have a Java app running under Websphere Liberty on IBM Bluemix. I need to be able to authenticate users 3 different ways - Basic Auth, SAML SSO, and OpenAuth SSO, in that order.
I can set up the app to do Basic Auth (using custom code) or SAML SSO (using the Bluemix Single Sign On service), but can't figure out a way to configure it to handle both at once. (I haven't even looked into how to do OpenAuth yet.) If I configure the app to use the Bluemix SSO service, then my app never sees the incoming requests to check for a userid and password to try Basic Auth before the SSO service grabs it.
I tried changing the redirect URL in the SSO service to an endpoint inside my app, but then all I get is
CWOAU0062E: The OAuth service provider could not redirect the request because the redirect URI was not valid. Contact your system administrator to resolve the problem.
I can't be the only one that needs to do this. Can anyone tell me how they did it?
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 .
Ping Federate Logout From IdP flow as from the Ping Federate Documentation
Sequence
User initiates a single logout request. The request targets the
PingFederate server’s /idp/startSLO.ping endpoint.
PingFederate sends a logout request and receives responses from all
SPs registered for the current SSO session.
PingFederate redirects the request to the IdP Web application’s
Logout Service, which identifies and removes the user’s session locally.
The application Logout Service redirects back to PingFederate to
display a logout-success page.
But, I have a slight problem regarding the application Logout Service , which needs to set at IdP adapter configuration.
The problem is i have dynamic logout URL , due to which i can't use it in the Logout Service.
Currently i am trying to initialize the IdP initiated SLO. For which i am passing TargetResource to redirect user to IdP after SLO success.
https://idp.pf.com:9031/idp/startSLO.ping?PartnerSpId=testSpId&TargetResource=http%3A%2F%2Fdynamicsubhost.baseurl.com%3A8080%2Fweb%2Fmy-bank%2Flogout
Question :
So how can i rig the PingFederate setting to skip the Step 3 , so instead of redirecting to the IdP Logout service it redirects to TargetResource.
What i have tried :
I know it sounds cheesy , but actually i kept the IdP logout service to blank. But obviously it wasn't working.
P.S The awkward thing is when i was using same PF server for
configuring both IdP and SP server it was working well. But when i
switch to separate instance of PF server for hosting the PingFederate
Server the consequence is showing up.
You may add the "resume" parameter in your logout service redirect. This is how I implemented it in .NET. I have a web service that handles the SLO and calls this redirect:
Context.Response.Redirect(< SP Server DNS > + Context.Request("resume").ToString(), True)
This redirect will instantiate the Logout service and then redirect back to the value of the targetResource parameter that you specified when you called the logout service.
If your targetResource does not have a value the default SLO URL will be used (this is set in the Admin Console: SP Configuration > APPLICATION INTEGRATION SETTINGS > Default URLs)
For reference: Just review the implementation of the sample application that you may download here
https://www.pingidentity.com/content/dam/pic/downloads/software/integration-kits/-NET-Integration-Kit-2-5-1.zip