I've got a web application that needs to implement SSO with WIF. There is a STS already set up for authentication, and I can use it to log on just fine.
However the application also needs to accommodate anonymous users. So when a user first arrives at the website, I need to somehow check with the STS if he is already logged on or not. If he is, the STS would return his token (simple), but if he isn't, he should be simply returned to the website without any further authentication, so he can continue browsing anonymousley (how do I do this?). If he later wants to authenticate, he clicks the login button and we do the typical WIF authentication dance, which I have already in place.
So... how do I tell an STS to do nothing if a user isn't authenticated?
There's nothing special really with WIF. You just define in your app what requires auth and what doesn't.
In MVC you would use the [Authorize] attribute on controllers. In ASP.NET you can use this: http://msdn.microsoft.com/en-us/library/b6x6shw7(v=vs.100).aspx
You shouldn't mix authentications on your web site (relaying party).
All authentication related issues should be handled by the STS.
To achieve your goal you should allow anonymous users on your STS and return token to your web site (RP) with claims indicating user as "Anonymous" (or whatever You want to call him).
So basicly you have to "authenticate" user as unauthenticated :D.
This way you do not decide your GUI looks and availability based on whether user is authenticated or not but whether he has specific role or not (obviously user "Anonymous" wouldn't have any roles). This seems to me like a better approach.
Hope this helps.
Related
I need to login to Auth0 without login prompt on my intranet under certain circumstances.
I have a very particular use-case, where I have created a very special user in auth0 called "analytics" which has access to some of our analytics in Tableau.
I created it, so I know the login password and can create refresh tokens with unlimited life.
I had to create this user in auth0 and have it managed by auth0 because that's how our company access Tableau and I can't change this policy.
In another web application, which doesn't use Auth0 at all and has its own authentication methods, I need some users to have access to the ressources that the "analytics" user can access. (there also, no way to change this web application to use Auth0, because that's another company policy and I can't change it)
To achieve this, I have no choice but to allow all logged in users of the web application to be also automatically logged in as "analytics" in auth0.
Since this is an intranet, it is perfectly ok to hardcode a refresh token or login password. Also there's nothing too confidential about the analytics in question.
I know how to use the refresh token to call an API, but I don't know how to use it to "login" the user, e.g. his browser has the right cookie so auth0 knows that his browser is indeed him.
Is there any way to achieve this ?
I don't understand very well the OAuth 2.0 protocol, hence my question.
Is there a good way to implement 2-Factor authentication on an MVC web application that is using Windows Authentication?
I see examples that show how to implement 2-Factor on a Forms-based MVC app, but couldn't find one for a Windows-based MVC app.
Any help would be appreciated!
2-factor doesn't make sense in the context of Windows Auth. The application is authorized by the user's domain account. The security aspect lies on the domain-end, not the application-end.
However, if you're dead set on doing this, you effectively can't use Windows Auth. That sounds a little contradictory, I know. How you would have to handle this is use application-based authentication, such as Identity, so the web application itself would hold the user accounts. Then, you can authenticate via connecting to LDAP directly. You'll have to set all this up yourself, in other words; no easy set it and forget like you get with Windows Auth. With something like Identity, you can implement 2-factor auth, so you're golden there. However, instead of validating the password via your application's database and users, you authenticate via LDAP.
This is actually pretty common among enterprise-class applications utilizing AD. Typically, they'll have a script that you can run, as a consumer of the app, to periodically update the application's user database from AD, so all the same users with the same details exist in both places, except for the password, which remains solely with AD. This way, the application can associate its own data with its copy of the user, but authentication and authorization still happens at the AD level.
We currently have a typical forms authentication setup in our organisation; with a login page located at something like account/login. We want to retain this but also want to start securing some of our APIs with OAUTH2 ; essentially we are the provider.
From reading a fair bit about the subject Microsoft's OWIN OAUTH implementation moving forward isn't supported (e.g. vNext) and doesnt support all the flows with OAUTH2. Thinktecture's identityserver3 seems to be the "standard" and most complete solution there is currently.
I cant seem to find an example of using identityserver3 with an existing app that requires forms authentication.
We would be looking at using it in two different ways; one using the implicit flow using javascript where we allow a third party site to call our API once the user has logged in to us (using the forms auth) and the user has allowed the client to access specific scopes.
The other use case, I think , would use the authorisation code flow ; the client would be requesting this so it can auto login (much like a login with Facebook - but login with X company) or be already logged in if logged in our site.
Any help with these scenarios would be most appreciated.
I think it will not be possible to switch your app to OAuth without changing your existing login.
I would suggest you use Identity server with custom user store(https://identityserver.github.io/Documentation/docsv2/advanced/userService.html) to use your current user database. That way your existing login accounts will be used by the identity server.
You can then secure your APIs with OAuth using the Identity server. You might need to change the way your current app call the APIs too. This means users of the current app will be redirected to identity server's login page. You can brand your login pages using custom views to make it appear similar to the curent login page (https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html)
Imagine the following scenario.
User visits a site A (ASP.NET), authenticates using ADFS and gets a set of claims . At some point, they need to register for an additional service so they are redirected to a provisioning site B (ASP.NET) (also using ADFS – so SSO) where they register by entering their relevant details and are redirected back to A.
However, part of the provisioning process added attributes to a repository (normally AD) and we would like those attributes to form part of their claim set.
To do this they have re-authenticate? Is the best way to do this by forcing a federated logout? Would this be done by site A or site B?
If they are internal users using WIA, they would be logged in “behind the scenes” and the whole process would be transparent.
What if they are external users using FBA? Wouldn’t they have to log-in again? Given that this is not a very satisfactory user experience, is there a way around this?
There are some references out there that talk about writing a signed token as a cookie to the client browser and then the STS later authenticating the SSO token from the cookie. How would you do this with ADFS?
Have a look at the blog post I wrote about a similar scenario:
Refreshing Claims in a WIF Claims-Aware Application
In this case, the user is logged out locally but then redirected back to ADFS where they are "signed back in" since their ADFS cookie is still valid. This little hop is mostly transparent to the user and will update the claims.
I'm creating an MVC web site, and I want to mix forms authentication (the built in authentication) with Twitter authentication in my site (eventually it will have Facebook/Google authentication too).
The approach I'm taking is this:
- I let the logic to create users and validate users/passwords from the Forms authentication as it comes out of the box.
- I created a new users table where I save the name of the user, the id of the user in my site and the authentication service of that user ("Forms", "Twitter", "Facebook").
- When the user logs in using any of the authentication methods, I create a standard Authentication cookie, adding the user id and authentication service to the UserData of the cookie.
Now, I want the user to be able to stay logged in after he closes the browser, no matter which service the user used to log in. With this I mean, that if the user opens the site again, he won't have to authorize Twitter again on the site.
Right now, with the cookies approach, MVC loads the user information from the cookie and the user seems logged in when he enters the site, exactly what I want.
The problem is that if the user revokes my site's access, the user's authentication cookie will still be valid, and the user will appear as logged in, even though the authorization for my site was revoked.
My question is, is there a way to validate the authorization in the moment MVC loads the information from the authorization cookie?. I know I can use a custom AuthorizeAttribute and validate this on the AuthorizeCore method, but this will be invoked only when the user is accessing a ActionMethod that requires authentication.
Thanks for your help.
Write an HTTP module that implements IHttpModule and handles the HttpApplication.AuthorizeRequest event.