I've developed a single sign on strategy with login/logout/refresh on multiple domains with JWT Tokens. The SSO is managed via postMessage iframes as described here: Single sign-on flow using JWT for cross domain authentication
The problem I have is when the user has Third Party Cookies disabled in his browser.
Then there the postMessage technique with iframes do not work anymore:
When passing a message top-down (setting the cookie inside the iframe), it fails
When passing a message bottom-up (reading the cookie inside the iframe), it also fails
I therefore have to develop a fallback workflow for all users with disabled Third Party Cookies.
It works the following way:
User logs in an the auth server
A cookie isset at the auth server
User gets redirected back to pageA and another cookie (with the same content) isset there
User visits pageB and wants to login there
User gets redirected to the auth server. The cookie is recognized and user gets redirected back to pageB and another cookie (with again the same content) isset
All 3 cookies are now "in sync"
The problem now arises, when user refreshes his token on pageB. then he cannot refresh it again on pageA and he has to login again on page A
Because the TTL of the access token is very short, this is a very bad experience
My conclusion to this: If a user has disabled Third Party Cookies, drop the whole SSO. The user simply has to login on every page.
Am I right or is there something I am missing?
Related
I need to refresh the user linkedin access token without them having to go through the initial authorization process all over again. I have also looked at this documentation http://developer.linkedin.com/documents/exchange-jsapi-tokens-rest-api-oauth-tokens, but It doesn't work because my users authorize the app through regular OAuth and the article uses the JS OAuth. (Not sure, if there is a difference between two processes, and if there is a difference between access tokens received from each process). Even though, I'm already logged in another tab on the same browser,
it always prompts me to login to LinkedIn.
If I try IN.User.isAuthorized() it returns false though I'm logged in into LinkedIn and I can't seem to be able to refresh the token.
If I pass the user LinkedIn access token from my server to the JS and the user LinkedIn id IN.User.isAuthorized() always returns true even when I'm not logged in
So what I'm trying to ask is, is there a way to refresh the user linkedin oauth token thorguh JS when the user is logged in to linkedin on the same broswer like we are able do for facebook ? and what is it ?
You cannot refresh the token without the member being at your application.
If you want to refresh the token, the member needs to be there and you need to direct them through the authorization page. If they're signed in to LinkedIn, this will be a seamless refresh and we'll redirect page to your application.
I have an ASP.NET MVC application which uses Google+ sign-in to authenticate the user. The flow is as follows;
User accesses controller action decorated with [Authorize]
attribute, forms authentication is configured so the user is
forwarded to the log in page.
User clicks the Sign In with Google+ button and the server side flow is initiated as per guide
Server receives the Google tokens which are used to authenticate the user, logging them in and returning the standard asp.net auth cookie in the response. The user can then access the site with the cookie.
Now, if I go through the usual asp.net forms log out process of clearing the user's cookie/session there's a problem. If they attempt to access the application after they've logged out but are still signed into a Google product in another tab, they'll be re-directed to my login page. The Google+ sign-in button will automatically sign them back in again initiating the whole sign in process and getting a brand new asp.net cookie!! The only way to truly sign out is to ensure you are not signed into any Google products still and then attempt to sign out. Not exactly user friendly. I guess the same thing happens with all Google products, if I'm signed into Gmail and open Docs, I'll get signed in automagically. The difference being if you sign out of one, you'll sign out of all Google products. I think.
There is currently not a supported means of logging the user out from your site. What you can do is force the user to click the Google+ Sign-In Button before they will be authorized unless you have set a cookie on their client indicating they are signed in (or enrolled, if you want to distinguish between the sign-in action and being signed-in). You can look at this question:
how do i sign user out of my app?
or this question:
Preventing automatic sign-in when using Google+ Sign-In
for discussions on this topic on stack overflow and answers to similar questions.
I have this scenario.
RP with passive federation to 2.
Custom STS for user/password authentication
Everything is working fine. So far the user would press login link, which would go to a restricted area, thus the federation security was triggered, and login screen appeared. It would prompt him to write the credentials, the request was then processed, etc.
Now I'm required to create login (user/password) text-boxes on the same page (default page). How can I achieve federation sign-in operation without redirecting to a login page? Should (or can) I use FederatedPassiveSignIn control? If so, how?
You could show the login boxes on the unprotected landing page if IsAutheticated is false and then send a message to the custom STS login page with the credentials encrypted or whatever which then logs in behind the scenes and redirects back to your app. with the token in the normal manner.
However, if the user is not authenticated and bookmarks a page behind the landing page, they'll be redirected to the STS.
For anyone interested (I doubt someone actually is), I've solved it through - basically - simulating what login page does.
// makes credentials validation, and creates IClaimsPrincipal with the acquired claims
IClaimsPrincipal principal = LoginHelper.SignIn(editEmail.Value, editPassword.Value);
// retrieves the instance of the STS (in this case my custom STS)
TrustedSecurityTokenService service = (TrustedSecurityTokenService) TrustedSecurityTokenServiceConfiguration.Current.CreateSecurityTokenService();
// creates the request manually to point to my original page (or whatever page you desire)
SignInRequestMessage request = FederatedAuthentication.WSFederationAuthenticationModule.CreateSignInRequest(Guid.NewGuid().ToString(), "http://page/i/want/to/go/after/the/validation.aspx", true);
// processes first the request...
SignInResponseMessage response = FederatedPassiveSecurityTokenServiceOperations.ProcessSignInRequest(request, principal, service);
// ...then the response is processed, and redirected to URL above
FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse(response, Response);
This created cookies, and principal is not IsAuthenticated. As if it were process by login page (at least it seems to work so far as expected).
Hi I'm using the FederatedPassiveSignInControl on my asp.net site (called ChildSite) to get an user identity from a STS which is set up on another asp.net site (called ParentSite). The authentication of my site (ChildSite) is set to FormsAuthentication, so the FederatedPassiveSignInControl is located on ChildSite's forms authentication login page.
I have 2 scenarios. In the first the user logs in to ParentSite and continues to ChildSite via a link in ParentSite. In the second the user goes directly to ChildSite and logs in to ChildSite:
Scenario 1:
User opens ParentSite in browser
User logs in to ParentSite
ParentSite displays a link to ChildSite in browser
User clicks link to ChildSite
User goes to child site
Here the user comes to login page.
Wanted behavior is that the user is seamlessly redirected to the requested URL at ChildSite as he has already signed in at ParentSite.
Instead the login page is showed and the user has to click on the FedratedPassiveSigninControl button to retrieve his identity and then be redirected.
I cannot set the FedratedPassiveSigninControl property autosignin="true". It would always redirect the user to ParentSite when not logged in and that would break scenario 2.
I wonder how I detect, or how I get FederatedPassiveSignin Control (or other WIF components) to detect that the user is already logged in, not show FedratedPassiveSigninControl and just forward the user to his requested page.
Scenario 2:
User opens ChildSite in browser
User enters credentials in text inputs at ChildSite and clicks log in.
The requested page at ChildSite is displayed.
Am I missing something here?
Cheers,
mortb
The simplest approach would be to add an additional querystring parameter to your 4th step in Scenario 1 so that when you finally get to your login page, you have an "if" : "if the querystring parameter is present then AutoSignIn = true".
This is known as "home realm discovery" although your scenario is not typical as hrd usually involves two or more stses and here you have to differentiate between the sts and forms authentication.
This looks like a classic SSO scenario. ParentSite and ChildSite should probably be 2 different relying parties. If user goes to ParentSite, then whenever they hit a protected resource (anything that requires user to be authenticated), then they will be redirected to the STS for authentication. A session is established between the STS and the user browser and then and then the user returns to the ParentSite with a valid token (assuming a "happy path").
When they hit a protected resource on the ChildSite (e.g. through a link on ParentSite) they will be redirected again to the STS (e.g. they will be requesting a token specifically for ChildSite, a second Relying Party). This time, because there's already a session with the STS, the authentication step is completed already and a 2nd token is issued. All this works seamlessly for the user.
This chapter of the "Claims Guide" covers this scenario: http://msdn.microsoft.com/en-us/library/ff359102
An additional note: credentials should not be entered in any of the sites, but in the STS.
I want to enable Facebook authentication and the FB-Graph in my website, which already has forms authentication. Using http://multitiered.wordpress.com/2010/08/05/getting-started-with-the-facebook-c-sharp-sdk/, I was able to figure out how to login server-side.
However, the problem with this approach is that a secure cookie will not be created, since the call returns the authentication code in the querystring via a callback. This means that the user will have to login every time.
I can see two ways around this:
Store the access token in a secure cookie manually
Instead of the above approach, use the FB JS API to login - this stores a secure cookie with the access token automatically
I would prefer not to use the second approach, as I would like the login code to be server-side.
Which would be the better approach? Am I missing something?
I use the JavaScript method to first authenticate the user, the JS SDK then writes an encrypted cookie (called "fbs_[YourAppID]") when a connected user hits your page; using one of the many Facebook c# SDKs, this cookie can be decoded using your application secret giving you the user ID, oAuth token, expiry date etc.
Then I hook into the AuthenticateRequest event of my .NET application, check the presence of the cookie, decode if it found, and then find a user who has been assigned this facebook ID (your user table must have a extra field for storing the ID of their facebook account).
If a match is found, I write a normal forms authentication cookie for this user, then .NET will recognise them for all future requests. If no user is found, then this is a brand new user who has just connected. Use the SDK again to query the graph API using their oAuth token, get things like their name/email etc and create a new account, then issue a authentication token as normal.
By writing a normal authetication cookie, the user will stay logged into to your site for all requests, just as if they were a normal user.
One side point, when using email address, check for duplicates, and check for the facebook cookie in all requests. For example, an existing registered logged in user may have just connected.