I have a web site with an initial login page, on this page I'm using a claims based identity which is authenticated when a user successfully logs in.
This all works fine, from this main site I have a number of 'sub sites' (that also require logins), and I'm looking to use the same authenticated identity to log into these (e.g. so a user does not have to enter login details every time).
Is there a way to pass the initial authenticated claims-based identity to these sites securely? If so could someone point me in the direction of any useful material on this?
EDIT
Just to clarify in response to the answers below, I am currently using Single Sign On and have this working as follows.
User logins in to https://mywebsite.com/loginsite with Single Sign On. Claims-based identity is authenticated.
What I'm wanting to do is use this same authenticated Claims to log in to the following url in the same domain:
https://mywebsite.com/website1
But whenever I try to access the Identity the authentication is false. Is there a way to achieve this?
What you mentioned is generally referred to as SSO (Single Sign On). See the Auth0 page How to Implement Single Sign On for one way to achieve this.
Single Sign On works by having a central server, which all the applications trust. When you login for the first time a cookie gets created on this central server. Then, whenever you try to access a second application, you get redirected to the central server, if you already have a cookie there, you will get redirected directly to the app with a token, without login prompts, which means you’re already logged in.
(emphasis is mine)
Disclosure: I work at Auth0.
Related
We have several websites that use same authentication method. The account and authentication is via a third party system and we developed library to authenticate against in C#. The user would enter a user & password and C# library will pick it up and do the authentication.
Following is what we are asked to implement
A user logs into any one of the sites. At that time a token needs to be created it should be good for a period of time.
If the same user tries to access another of our site, user should automatically log in because there is an unexpired token from step 1.
Is there a way to implement this? From what I know all the cookie and storage are per site and one site's cookie cannot be accessed by another one. If one site can access another ones token that is a security breach to me. So is there anyway to achieve this?
With the use of IdentityServer4 and the OIDC protocol, I've managed to get my SPA and my .net core web api authenticating against a sql server user store, as well as ADFS which is great. However, when the user first clicks the 'Continue with ADFS' button, the login prompt is shown asking the user for their credentials. My understanding was that with the use of openId connect and IdentityServer, we could add external identity providers such as ADFS to our IdentityServer application and if ADFS is chosen for login with the user already logged in to ADFS via their local machine, then the authentication would happen seamlessly without the need to input windows user credentials again. There are other steps in order to achieve this of course, like linking the ADFS UserId with our SQL Database User Id table, but overall my understanding was that this would be entirely possible.
After a user logs out from an ADFS login, the next time the user chooses to log back in with ADFS, the 'Challenge' method that is run within my IdentityServer application to initiate the redirect to ADFS often recognises that the user has already logged in recently and therefore just logs them right in without the need for their credentials again.
My question is - is it actually possible to avoid the initial login prompt altogether? Or will the browser insist that credentials are provided if the user hasn't logged into the application for a while?
It certainly is possible but it may involve specific browser config in ADFS and also may require your IDP to be in the intranet zone in Windows Internet settings.
Check out these articles:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-intranet-forms-based-authentication-for-devices-that-do-not-support-wia
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia
I have scoured this and many other sites to find an answer but have come up short every single time. If this is a duplicate, I am very happy to accept direction to the original question with an answer:
I have built an MVC 4 site and I am using the Authorize tag where needed and this is working as expected.
My issue is that I require a mechanism by which to prompt the user (already logged in or some other valid user in the domain) to enter their windows credentials on one page in order to confirm/authorize that user. This is not what the authorize filter is doing. The authorize filter is actually authenticating the user. Thus changing the User.Identity information accordingly.
Is it possible to just authorize a user (not authenticate) without actually changing the User object?
Just returning the 401 response forces the windows prompt but that, in turn, does an authentication, not an authorize.
While a solution could be achieved with a custom action that accepts username/password input, my requirement specifically calls for the native browser windows prompt to be displayed.
The site is using IIS Express and is set up for windows authentication and every aspect of this does what I need. Except for the issue of "true" authorization mentioned above. The browser has to be IE9. Currently running on Windows 10.
No. You're currently using Windows Authentication, and this is how it works. There is no need to login because the user is already logged into Windows, that's the point.
To do what you want, you would need to use an individual auth library like Identity. Which will give you the login capability. However, that doesn't work with AD out of the box, but you can add that in yourself. In otherwords, instead of using the Identity functionality to look a user up by username and password to authenticate, you'd connect to AD over LDAP, and verify the credentials there. You'd also need to use the LDAP connection to add the user's groups in AD to the their roles in Identity. Then, you can utilize the Authorize attribute as normal.
Long and short, if you want to actually allow the user to login as any AD user, then you're pretty much on your own. There's no builtin functionality for that. It's relatively straight-forward, if not entirely easy, to set something up yourself for that that, but again, that's on you.
In my environment I have presently two applications, lets call them portal and sso. Portal is where I manage user accounts and allow people to register. SSO is my implementation of IdentityServer. I want to require users to reset their password after 90 days or after they had their password recovered for them. I can check for this in the AuthenticateLocalAsync function, but the question is how do I redirect them to the portal password reset page? Or is it easier to add a custom page to the IdentityServer to handle password resets of this nature? Are there any examples of this, specifically where the identityserver is not embedded into the application using its login functionality?
Your best option is to create a "reset password" page in the same IdentityServer project, and issue a partial login redirecting to that page every time an user with expired password completes the sign on process successfully.
With this approach you can catch users with expired password before they are effectively logged in, without completely breaking the login flow.
You can find some details in the IdentityServer3 CustomUserService sample, specifically in the "EULA" sample which uses "EulaAtLoginUserService".
I do not think there is a way to directly redirect the user to an external endpoint (e.g. your Portal residing in another domain) during the IdentityServer login flow.
I'm in the process of building an expanded login/signup area for my website which includes OpenID, OAuth (Twitter) and OAuth 2.0 (Facebook) sign in options.
Once a user has authenticated successfully and I've stored their access tokens in my database and written a cookie linking the user to their login state, what best practice should I be using to determine that the user's access token is still valid? It seems that having to call the authentication provider for every single request to my site would slow things down for the user and I can't imagine that is what other sites are doing.
My guess is that I should store a cookie which is valid only for the current browser session and thus that cookie will expire when the user closes the browser, forcing a new access token to be generated on the next request (and a new cookie to match). I would also expire the cookie early if the user explicitly logs out.
The only question I have of course is if, for example, the user has my site open in a tab, then they open their authentication provider in another tab and sign out of that site, but continue to browse my site, they won't be logged out of my site, even though technically they're supposed to be able to log out using the third party provider.
Is this one of those "it doesn't really matter" scenarios, or am I approaching the whole thing the wrong way?
Definitely the service providers do not want you pinging their service for every request that comes into your service. Even Google balks at the thought of that. You could set up some kind of a timeout to check every 5 minutes, but I think your idea of a session cookie is the ideal one. But yes, it depends on what you're trying to achieve.
If you are just using these services to log the user in and that's it, then throw away the access token you have as soon as you verify the user is logged in and set your own session or persistent cookie. You don't need their access token any more.
If you do want to access the user's data on these services, then of course keep the access token around. But you still probably should maintain your own concept of whether the user is logged in. If I recall correctly these access tokens are typically long-lived (in OAuth 1.0a anyway) and they won't help you when the user returns to determine whether the user is who they say they are unless either you have your own cookie or you send them through the login service again.
If you are just using OAuth / OpenId for login purposes, I don't think you should worry about any of it.
What you should worry about is if your users are who they say they are as their (OAuth/OpenId provider) users.
If your website intends to interact with Twitter and Facebook, that's a different matter, but still it pretty much solves itself. When you try to interact with FB, while your user has logged out of there, FB will prompt your user to login again.
Bottom line, I think it's really a non-issue.