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.
Related
Following scenario: I'm successfully authenticated in application A, token and cookie is issued. Later I go to the application B. Application B is ASP.NET MVC application. Now when I click the Login button I'm, as expected, successfully logged-in without redirection to the Login page. But I would like to be logged-in without to click on Login button. So when I come to the home page the button shows "Logout", but do not redirect anywhere when I'm not authenticated, until I click on the "Login" button. Now I'm using standard OWIN Middleware and Authorize Attribute. What is the proper way and alternatives to achieve this? Need I write own Authorize Attribut filter?
From the 2nd app you can trigger a "silent" login attempt via an iframe passing prompt=none in the authorization request. If the user is already logged in, then they will get a response immediately (success of failure). Check the docs for the params: https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html
I have a ASP.NET website where multiple users access the site using same user credentials. The site functions fine when used by single user, however when a second user with the same credentials logs in simultaneously and the first user performs any action (clicks any link, selects any dropdown etc.), the first user is redirected to the default/login page. I want both the users to access the site without any trouble.
Can any one comment on why this is happening and how this can be solved.
My guess for the reason of the behaviour would be the authentication method you are using. Probably when the first user logs in he gets a session ID that authorises him for the following requests.
When another user uses the same credentials to log in, different session ID is created for that user so the ID the first user has is not valid any more, and therefore he gets redirected to the login page.
I'm developing a Sina Weibo integration and I'm doing the oauth correctly but I have a problem with authorization page. When I click on enter, I accept authorization page and I can loggin correctly but if I log off and I try to clic another time enter, I can only see a login page, but no an authorization page.
How can I force that an authorization page shows always?
The correct login flow consists of the following:
1. redirect user to the authorize page with the app's client id
2. client logs in to weibo (authentication)
3. client grants the application requested permissions (authorization)
4. client is redirected to your app page.
I believe the step you are asking about is #3. Once a user has granted your application permissions, this will be stored on their weibo account. The user will no longer be prompted to grant permissions every time the user logs in. The exception is when the user has removed your application from their weibo account. Thus there is no way for your application to force the user to reauthorize your app every time. It is unclear under what circumstances this would ever be required/beneficial.
As a side note:
If a user is already logged in, #2 is skipped by default. The user can be forced to relogin with the forcelogin parameter described in the docs: http://open.weibo.com/wiki/2/oauth2/authorize/en
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).
I am developing an intranet asp.net application. We will be using Windows authentication, so the authentication mode is set to windows in web.config.
I want to restrict some pages to only certain users so I am using the
tag with the tag to allow/deny certain users.
Scenario :
User1 is not allowed access to page "Reports.aspx" (this page has restricted access using the authorization tag in web.config)
User2 is allowed access to this page.
Both of them are in the MYCOMPANY domain.
When User1 tries to access this page he is shown a credentials popup - he will enter the details of "User2" since user2 is allowed access ; subsequently, user1 is now able to access this page(by using user2's details).
Now user1 goes back to some other page which is not restricted by authorization tag. Lets say he goes to homepage. Now again from homepage, he will try to access Reports.aspx. At this point logically speaking, again a prompt for login credentials must come up . But instead no popup comes up and the user1 is allowed access to REports page.
I decided to check the username using HTTPContext.Current.User.Identity.Name in this scenario. When the user1 is trying to access Reports.aspx for second time(after having logged in successfully first time) his credentials are being stored in the browser(I guess) because this time around, when the page loads, the credentials show up as User2 in code behind.
How to prevent this and force a login prompt every time for this page ?
Guess I was a n00b back when I asked this.
For the benefit of people who might have faced a scenario - when you login again, the original credentials are no longer maintained and ASP.NET always recognizes you as the User2 hereafter.