We are trying to implement Single sign on (sso) using SAML 2.0 using ADFS with our customer site.I have successfully set up ADFS and when i access ../adfs/ls/idpinitiatedsignon.aspx page it shows "Sign in to this site" radio button and it redirect to customer site and asks for Username and password and once entered customer's site user name and password then it brings back to idpinitiatedsignon.aspx and says "You are signed in" and shows sign out button.But i'm unable to get the logged in user's details from HttpContext.Current.User in idpinitiatedsignon.aspx because HttpContext.Current.User.Identity.IsAuthenticated is false but IsAuthenticatedis true. So how can i get the logged in user information ?
Because when you call FormsAuthentication.SetAuthCookie(txtUsername.Value, true); you store the key on the client's cookies. For this you need to do a response to the user. And for HttpContext.Current.User.Identity to be filled with cookie you need one more request.
In short your scheme looks like this:
Client sends his UserName and Password.
Server gets and checks it.
If they are valid the server sends Set-Cookie header to the client.
Client receives and stores it. For each request client sends cookies back to the server.
Related
Description
In my mobile application, the user tries to access a resource which requires authentication.
After logging in and obtaining the access token, I want to redirect them to the originally requested page (the return Url).
Question
In a token-based authentication, how to redirect to the return url?
Example
Consider this scenario:
1 - I have a menu in my mobile application "My Profile" which opens a WebView and navigates to mycoolwebsite.com/myprofile.
2 - The server (MVC controller) redirects to a Login Page with the returnUrl as in the URL. mycoolwebsite.com/login?returnUrl='/myprofile' because user cannot access mycoolwebsite.com/profile without logging in.
3 - User sees a Login Page, they enter their username and password, and press the Login button.
4 - A POST request will be send to the _Token Endpoint _ of the ASP.NET application, including username and password and grant_type of password
5 - The server validates the credentials, and issues a Token. It will send the token back to the client as a JSON object.
Problem: after obtaining the Token, I need to redirect the user back to mycoolwebsite.com/profile which they originally requested.
In an ASP.NET MVC application, this happens automatically with the MVC template.
However in WebAPI, I'm not sure what is the proper way to do this.
With Cookie Authentication it works like this:
User submits the login form, making a POST request to mycoolwebsite.com/login?returnUrl='/myprofile'
The server authenticates the user and if the authentication is successful it returns 302 Redirect response with Location and Set-Cookie headers. Location header contains default redirect url (usually "/"), or value from returnUrl parameter (in this case "/myprofile").
Finally the browser sets the authentication cookie and then redirects to the new location.
Bearer Token authentication (most likely your case)
The user fills the login form and make an Ajax request to mycoolwebsite.com/token
If the authentication is successful the server replies with 200 OK status code and returns the accessToken.
The client then reads the response body and store the accessToken for further use. Now it's up to you. You can read the returnUrl parameter from URL and redirect user to mycoolwebsite.com/myprofile.
So the difference between these two is that the redirection occurs on server-side (via 302 Redirect response) or on client-side.
Hope it helps.
I want to use the Windows Live Id Authenticaiton in my Asp.Net/MVC web application, but I do not want to use the Login screen provided by Microsoft.
I want to have my custom page for login, take username and password from User and then send these credentials to the Windows Live ID, to Authenticate, and I get back the response if the user is authenticated or not.
Is this possible?
I want to have my custom page for login, take username and password from User and then send these credentials to the Windows Live ID, to Authenticate, and I get back the response if the user is authenticated or not.
You missed the point of single sign-on authentication. Using that, the user does not provide their credentials to your site, but to the SSO provider. That provider gives you a token which lets you act on behalf of the authenticated user.
The user's credentials are never received by your site.
So no, you cannot, nor should you want to, do this.
I think that internal mechanism of authenticaton should set a cookie with a token and store the same token on a server and next on every request compare the tokens from the cookie and on the server and if they are equal then user is logged in. I don't know where a server stores token, maybe in Session or something else (not persistent), but I'm sure that after the server's restart the server's tokens's store should be cleaned up therefore a user with an old cookie can't be authenticated. But in a practice after I restart my server a user is still authenticated and have access to pages because User.Identity.IsAuthenticated returns true. It seems to me wrong. Even if I remove this user from my DB (I use Membership) because I don't want this user have access anymore and restart my server, the user is still authenticated. Can anyone explain this?
Source of answer
Here is how authentication process works.
You setup some stuff in your web.config around where the login page is, how long the login is good for and whether or not to use sliding
expiration (should the time be extended if the user is active on your
site)
User comes to your site, enters their username and password.
That information is posted to your server. You take that information, verify that it is correct (authenticate). If it is
correct, the server then issues an encrypted cookie known as the
FormsAuthenticationTicket Note - this could have a different name in
the new Identity stuff, but the same principle.
The cookie's contents includes items such as the user name and expiration date of the login.
On each request, the server looks at the cookie collection for the authentication cookie. If found, it decrypts it, reads the values and
determines if this is still a valid cookie (expiration time). Once it
has the user information from the cookie, the server can use this
information to determine if the user is authorized for the resource
requested (look up by username).
If the cookie is not present, or has expired, or When the user logs out, the cookie is deleted from the cookie collection. Now, if the user tries to go to a resource that is for authorized users only, then the user is redirected back to the login page.
Hope this helps.
I am configuring Azure ACS with "Google" configured as IdP in my application. My requirement is that I do not want the IdP login page to be displayed every time I try to log into my application. I have set my ACS token lifetime to the maximum period so that my token is valid for a day.
First time when I log into my application and I select "Stay Signed In" in Google login page, I am able to log into my application. I now close the browser, reopened the application, I am successfully rediercted to the application home page without any credential request. (as ACS internally uses the session token created intenally which will be used in next requests)
But if I do not select "Stay Signed In" in IdP login page, and proceed the same steps, I am asked for credentials. Any idea why is this happening? Is there a way I can manipulate the session token and validate the ACS token which was earlier issued to me ?
When you select "stay signed in" at Google, it writes a persistent cookie, meaning that you'll stay logged in even if you close your browser. By default, your application's cookie is scoped to the session (assuming you're using WIF). When you close and reopen your browser, the original token and cookie are gone. Your browser redirects to ACS, which redirects to Google, which redirects you back again because of the persistent Google cookie. Running your session using Fiddler or HttpWatch should show that, even when you choose "stay signed in", you're still being sent back to ACS and Google and getting a new token.
It sounds like what you want is your RP to "remember" the user so they don't have to log in again within the token lifetime. To do this, your federated cookie (the one with the token in it) needs to be set as persistent, rather than session. If you're using WIF, this can be done using CookieHandler configuration on the FederationAuthenticationModule (see PersistentSessionLifetime).
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.