in chrome extension application it has a url like chrome-extension://lcoibdhlihchjibnocnoofbfobniiofp/index.html
and it request to server to authenticate using SNS Oauth
Flow looks like these
chrome extension -> API server -> google -> API server(callback) -> chrome extension (redirect to)
the situation is
if browser keeps google oauth session it works well
initiator accounts.google.com request to API server using callback endpoint
and it redirects to chrome extension well
but
if browser doesn't keep session so i must enter password to authenticate browser blocks redirection
I have no idea where to check to fix the issue.
diff
i got new difference between two situation
the one Oauth session is not kept
the other Oauth session is kept
could possibly initiator matter ?
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,
I'm working on an enterprise application and our UI is a web application. We are looking to add OAuth2 support and I don't understand what to provide for the redirect URI field to the OAuth provider.
For example, I have registered my app in github OAuth provider.
Homepage URL: https://localhost:7980/index.html
Authorization callback URL: https://localhost:7980/oauth_callback
Now this works fine with localhost as the hostname. But, when this application gets used by the customers they can install it on any of their boxes and invoke the web app from any device connected to our server via https://[hostname]:7980/index.html. In this case, if the customer wants to use OAuth2 authentication option, then I don't understand what should be the redirect URL. Obviously I cannot use localhost for redirect URL as the customer can access the web app from any machine. I wouldn't know the machine ip/hostname where the customers are going to be installing our server beforehand.
One suggestion was to use a server from our company which would handle redirect URLs for the OAuth2 authentication. Is this a good idea? Is there a standard way for handling the use case I have narrated above in OAuth2?
I have encountered the following FB error:
Given URL is not allowed by the application configuration: One or more
of the given URL is not allowed by the App's settings. To use this URL
you must add a valid native platform in your App's settings.
Also Facebook OAuth redirect URI, does not accept http local host.
You may need to review the OAuth settings for your Facebook application
Also Facebook OAuth redirect URI, does not accept http local host
HTTPS is required for new Facebook integrations. You can get free certificates from Lets Encrypt or use self-signed certs and add them to your mobile device. It's a little more complicated, but it's really for the best :-)
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.
I'm having a application which has Windows Integrated Authentication, for internet users we are having a reverse proxy which has a IIS server which will authenticate using basic authentication then redirected to the actual application, every thing works as expected in IE and firefox but in safari there is a second login dialog box appers.
When I did a packet capture using wireshark I noticed that in IE and FF the basic authetication which is carried forwared to the actual application from IIS server but in Safari there is a NTLM negotion in between because of this my application asks for one more login dialog. Dose any one knows why safari is behaving like this?
It seems like there is an issue with basic authentication and HTTP redirection