Scenario:
I have two application to which login is done using pingfederate single sign service.
1.User try to login into first application but as user is unauthenticated user is redirected to login page of pingfederate (universal sign in page). User logs into the first application.
2.User try to login into second application as user was already authenticated by single sign service pingfederate provide application with necessary information(information required to set session) and user is redirected to second application.
Problem:
When User logout from first application then user gets logout successfully. At this point pingfederate knows about all open application and send then logout callback. So it sends logout request to second application. Second application handles the logout request and clears the session. But user stays on the same page. user is not redirected to the login page
Question:
How can be this be implemented that when we receive logout request redirect user to login page?
The way SLO is supposed to work for SP-Init SLO is:
You click logout at the FIRST SP application.
You are redirected to the IdP with a LogoutRequest.
The IdP then sends you, serially, to all the other SPs with
LogoutRequests. Every one of those must provide a SAMLResponse back
to the IdP with a status.
The IdP, after receiving the final status, must send the
user/browser back to the originating SP with a SAMLResponse with the
final status, which the SP acts upon.
In IdP-Init SLO, it's basically only step 3.
Here's the kicker, though, and I think gets to the heart of your question. If a single one of those SP's "misbehaves", i.e., does not respond to, or support, SLO (there is no requirement for them to support SLO), then it will break the "chain" of logouts, if you redirect to it! The IdP will redirect off to the SP, and the there the browser will stay. Once the chain has been broken, there is no way to get it started again.
I discussed this problem in my blog post "SLO - Proceed With Caution", a bit more than a year ago. Ultimately, with many of the big-name SP's out there not supporting SLO, there's not much of a reason to do it - it's just going to give you, as an SAML administrator, a black eye. Or heartburn. Or both.
Related
Slack provides the ability to make a Direct Install to install your application.
When you save your Direct Install URL, Slack will attempt to send a simple HTTP GET request to your declared URL. If it doesn't detect a HTTP 302 redirect pointing back to a fully qualified slack.com/oauth/authorize URL (see below), you'll receive an error letting you know.
...
First Slack sends the user to your Direct Install URL:
GET /slack/direct_install HTTP/1.1
Host: example.com
Then your server kindly redirects back to Slack's OAuth 2.0 authorization page:
HTTP/1.1 302 Found
Location: https://slack.com/oauth/authorize?client_id=12345.67890&scope=channels%3Ahistory%20users%3Aread&state=abcdefg
Resulting in the user jumping right into authorization. One point of friction removed.
You may continue to generate your own time or context sensitive state parameters and specific, pre-registered redirect_uri values as needed.
How does this integrate with my own apps user authentication? As I read it, the Direct Install URL must always 302 redirect to the Slack OAuth page. If the user isn't logged in to my application when they click the "Install" button, what am I meant to do?
My best guess is that I should:
Always redirect to the Slack OAuth URL and generate a state parameter to keep track of the request.
When the user finishes their authentication, they are redirected back with the code and state parameters.
If they aren't logged in, ask them to log in, and retain the OAuth code and state parameters. Once the user logs in, continue with the OAuth authentication process.
Is that right? Is there a way to force the user to be signed in to my app before trying to install the Slack app?
On a security note, for this to work with session cookies, I think they would need to be set to SameSite=lax, not =strict. The cookie wouldn't be passed from a cross domain request when they are set to strict.
I think you have a couple of options:
1) Don't use it.
The "Direct install" feature is a shortcut to the standard "Slack Button" installation process. Since in your case the user needs to first log into your app anyways, I think it would be more user friendly to also provide the Slack button in the same context on your webpage.
2) Return an error
If you detect that the user is not logged into your app, you could just return an error to Slack, e.g. http code 500. Slack should then also return an error to the user (not sure how it looks though). If you combine that with a clear message on your Slack App install page about the requirement to first login to your app that could work. This would be the easiest to implement, but also the least user friendly approach.
3) Request login to app after Slack login
After you completed the Oauth process and recognize that the user is not logged into your app you could request the user to login to complete the installation process. The disadvantage here is that your app would already be installed and could be left in an unusable state if the user failed to login at this point.
4) Halt Oauth process for user login
As you suggested you could halt the Oauth process after receiving the authorization code and request a user login to your app. Then continue the Oauth process after a successful user login. This can work if you need to take into account that the authorization code will expire after 10 mins. I do not see any way of forcing the user to login before he clicks on the direct install button.
I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.
I'm using hosted screen of Auth0. I want the following scenario to work-
Let's say I have 2 apps- app1 and app2.
One of the users signed in by providing email+password in app1.
User then navigated to app2.
Auth0 detected that the user has already signed in, so it redirects the user back to app2 WITHOUT having her signed in again.
But what I'm facing is this screen-
How can I save my user this additional click? How do I implement silent authentication? I know that you have to pass prompt=none to /authorize api, but since I'm not manually calling the api, how do I make the lock call /authorize with prompt=none?
What you want is silent SSO which is related to SSO but kind of independent.
The key is in the prompt param. This needs to be none in order for the user to not be prompted for login when he's already logged in Auth0's Authorization Server ("central SSO").
One annoying thing I found is that prompt is taken literally, so if the user is not logged in yet, he will not be prompted to login (you'd think it'd make sense to prompt the user when not logged right?).
In this case SSO will redirect to your app's /authorize with an error like "authentication required" and you'll have to handle it by redirecting the user to your /login endpoint again but passing prompt=true so that it knows that this time he'll have to pass prompt=true to Auth0's hosted login page.
To make things a bit uglier, currently passport-auth0-openidconnect seems to ignore the params you pass to the strategy unless you monkey patch one of the methods involved (I created a PR for it, don't when will be approved and/or if makes sense).
Essentially:
Pass prompt=none
If user is already logged in, he will silently be logged in your app as well
If user not logged in, user will be redirected to your app with "login required" error
In that case you'll have to pass prompt=true
I know it's a bit fiddly but I hope this helps you :)
PS: Another thing to bear in mind - I now just found out that it works perfectly when using Github as connection but when using google-oauth2 it blows up complain about the prompt param :|
I am using WSFederationAuthenticationModule for authentication. When the user is not authenticated it redirects them to ADFS web agent accordingly. The ADFS cookie lasts longer than the app session, so sometimes they will just be looped right back into the application.
Pretty much every time this is what I want, the user tries to do something, it redirects them if the session is expired and they come back around (either after logging in again or after it finds the cookie to still be good) and then they can do what they want. However, if they are clicking 'logout' I want them to be logged out. But the Module is intercepting and sending them back around and then they have to click 'logout' again once the session is restored.
Logout is an MVC api controller action. I am not sure if I want to take it out from behind the security because it also triggers some clean-up things for the app (I realize this is also a problem because potentially if they never click logout those things won't happen but that is a different issue).
I feel like I must be missing something with WSFederationAuthenticationModule and ADFS... something just doesn't feel right about making the logout action an anonymous/public action. There must be some consideration for this in the intentions of WSFederationAuthenticationModule but I can't seem to pin it down.
As far as I understand Your authentication is kept via an Auth cookie. You should try adding the following in your app controller under your logout action:
FederatedAuthentication.SessionAuthenticationModule.SignOut();
return View("LogOut");
This will log them out. Now if the "LogOut" view cannot be accessed by an unauthenticated person it will redirect back to your login page for login.
One more thing, if what you mean above is that after the session expiration when someone tries to access the logout page (although their session is anyhow expired already) they are first redirected to the login module to authenticate (since they need to be authenticated for access to the logout page), huh you could do something like this:
if (User.Identity.IsAuthenticated)
...u'r logout logic goes here together with other clean-up...
else
...u could choose to return a view which says he is already logged out
or on the login service side (if you control it) check where is the request coming from and take action accordingly.
I'm using DotNetOpenAuth. I configured my application with Custom form authentication with Gmail OpenID through (DotNetOpenAuth). I can successfully login to my app. But say for eg. i logged out from application and click login (with in 10 to 15 Sec) its not redirecting to gmail login. It generated authentication token by itself without asked from user.(I hope something is cached OpenID)
I used PAPE
request.AddExtension(new PolicyRequest()
{
MaximumAuthenticationAge = TimeSpan.Zero
});
And also tried to configure in web.config.
<openid cacheDiscovery="false">
Is there any workaround for the same.
NOTE : Once i logged out i used to clear ALL Session and call FormAuthentication.SignOut()
With OpenID, you as the relying party cannot force the login policy for the user at their Provider. You can request that the provider relogin the user as you have with the PAPE extension, but the Provider may still ignore that.
The cacheDiscovery setting is irrelevant to pass-through login, so I suggest you remove that entry as it will simply slow down all logins.
I think you're mistaken when you say it's not redirecting to Google. If you look at the logs, or what your browser's URL bar, Google.com should be redirected to, but at that point Google decides the user has a login session and avoids prompting them to login again, and redirects the user immediately back to your site.