Two questions:
1) How/where do I set the lifetime of the session cookie in my web application when using an STS to get claims? From what I can tell, it seems I can only do this programmatically in the ServiceConfigurationCreated event.
2) How/where can I make sure that the expiration is sliding?
StsDude, I asked your question here: How can I make a security token automatically expire in a passive STS setup?
A code sample for the answer may be found here: http://social.msdn.microsoft.com/Forums/en/Geneva/thread/a048694c-3548-4b4d-9bb3-0589c888fd02
Related
I am building a SPA using React and Redux on top of dotnet core 2.0. Unfortunately, the vs2017 template for this does not include Authentication/Authorization.
In looking around, I saw many people talking about the use of JWT's and suggesting things like Identity Server or OpenIddict to handle this, but I have only ever used ASP.NET identity to handle security before.
My question is, is it possible to secure a react app by using ASP.NET identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
I will try to answer by your questions.
Q.1. Is it possible to secure a react app by using aspnet identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Q.2. Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
Answer To First Question(this question technically related to difference between cookie based and token based authentication approach.)
Cookie based authentication system
cookie based session is StateFull. as here server needs track of active session,while on front end/client end a cookie is created that holds a session identifier.
you can secure your web api using cookie based authentication system. but in a very limited scope, because ,cookie based system doesn't work well, on native clients or suppose if your web api is going to be consumed by some other web api,
Token based authentication system
it is StateLess as server doesn't keep here the track of which token are issued or which users are log in.
Here server needs to verify only the validity of the token. so token based approach is more decupled than cokie based.
Sources
https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
Update Above(Auth0) link not working any more Updated Link
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/secure-net-microservices-web-applications/
Answer To Second Question
Yes you can implement cookie based authentication in spa by using OWIN Cookie Authentication middileware .
you can find more information regarding it on following link.
https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/
Hope above will help.
If you are going to have React and API in one domain, and the SPA would be the only client of API it may be recommended to use cookie based authentication with SameSite Cookies.
https://www.scottbrady91.com/OAuth/Cheat-Sheet-OAuth-for-Browser-Based-Applications
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/
(section same-domain apps)
longer post: https://blog.cdivilly.com/2020/06/10/oauth-browser-apps
In my solution I am using Thinktecture IdentityServer.
I wanted to introduce the remember me feature (persistant cookie) so I used AllowRememberMe option described here: https://identityserver.github.io/Documentation/docsv2/configuration/authenticationOptions.html
and that is working good but the persistant cookie is created only for IdentityServer instance - not for the client website which called for authentication.
My question is: Is there out of the box solution to achieve that? or do I have somehow pass deatils about cookie expiration through claims or so?
Of course identity server can only issue cookies for itself - not your applications. You would need to do that in your application code.
Some background
I work on an ASP.NET MVC web application which implements federated authentication using WIF.
For reasons beyond my control, I am forced to use a proxy STS which, on the one hand, serves as the IdP for my MVC app, but at the same time it implements it's own federated authentication via an ADFS server.
This way, the user authentication process in the MVC application looks like this:
User enters MVC application.
The application redirects the user to the proxy STS for authentication.
The proxy STS redirects the user to the ADFS server for authentication.
The ADFS server authenticates the user and redirects back to the proxy STS.
The proxy STS redirects the user back to the application, with the same authentication info which the ADFS server issued.
The ADFS server is not something I have direct access to (in terms of management), whereas the proxy STS is just a little service (implemented using this tutorial) which I control fully.
The problem (and what I tried to do to solve it)
Using the above setup, I noticed that the users' authentication wears off after about an hour, and then they need to be re-authenticated, so now I'm looking for a way to extend the authentication lifetime.
As of my understanding, it should be enough to extend the lifetime of the security token issued by the proxy STS, which I did. But it didn't solve the problem - the users still needed to be re-authenticated frequently.
So I tried doing the following things hoping it would help:
Setting the persistentCookiesOnPassiveRedirects option to true in the MVC application's ws-federation configuration with a 1-week long expiry time (to make sure that the auth cookie is not being lost due to session expiry).
Setting the HTTP session lifetime in the MVC app to last a week (to make sure that the security token is not being lost on the server side due to session expiry).
Setting the security token lifetime for tokens issued by the proxy STS to 1 week (which I made sure is being applied by examining the security tokens received by the MVC app).
Doing the things described in bullets 1 and 2 on the proxy STS as well.
Setting the IIS auto app-pool recycling time for the MVC app's application pool to be once a week.
None of the above didn't seem to solve the problem, but then I tried:
Setting the security token lifetime for tokens issued by the ADFS server to 8 hours.
As a result, the authentication duration got longer, even as much as 10-11 hours.
The question
What controls the authentication duration with WS-Federation in the above scenario?
Which of the above things that I tried should really be relevant to my issue, and which should not affect it at all (specifically, I would like to understand whether the ADFS token lifetime should really have any effect, and if so - why, or did I just have bad luck with my tests, and it was really something else that might have helped with the issue)?
Thanks in advance!
You have hit a lot of relevant parameters. I will talk about the WIF/.NET part and SAML Tokens only. Not about Pool recycling etc. They are different topics. You will have to take a look at the XML in the SAML messages and Tokens if you really want to control this.
One of the problems is that there are differences between SAML1 and SAML2 Tokens. Besides that some validity timestamps are in the SAML Protocol, which is not used between WIF and an IdP.
Summarized:
It appears that WIF uses Conditions for the SessionToken. That is the only thing available in SAML 1.1. OK there.
SecurityTokenHandler.ValidateToken(token) calls DetectReplayedTokens().
The SecurityTokenHandler.DetectReplayedTokens(SecurityToken) method verifies the validity if the incoming Token (SubjectConfirmationData #NotOnOrAfter). It is not present in SAML 1.1 there WIF uses Conditions#NotOnOrAfter.
This is essentially correct for Replay detection in SAML 2. Somewhat silly (too broad, too long) for SAML1.1.
Applications can (and do) override this behavior in TokenHandler(s) or in events of WSFAM and SesAM. See for instance Vittorio about Sliding Expiration.
I have a question connected with security.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
How is session id being sent in consecutive requests? Is it stored also in a cookie?
What are the drawbacks of using session instead of forms authentication for authentication?
Thank you
Using user session for authentication is a very bad idea from the security perspective. User session is maintained by a cookie (ASP.NET_SessionId), just like the authentication session (ASPXAUTH). However, ASP.NET has a lot of security safeguards built into the authentication session cookie management, such as encryption, validation, prevention of tampering, etc. None of these measures exist for the user session cookie, which makes it easy to break the site security.
There is absolutely no reason not to use forms authentication, it is actually more difficult to switch to using the session for authentication, because you have to custom code to support it.
Well, you got two questions.
Is it possible to implement authentication and authorization trough session variables without using forms authentication and forms authentication cookie stored in browser?
yes it's possible but we're not supposed to reinvent the wheel especially it is related to security. It's strongly recommended to use form authentication when possible unless you have strongly valid reasons.
How is session id being sent in consecutive requests? Is it stored also in a cookie? What are the drawbacks of using session instead of forms authentication for authentication?
to see the cookie.
step1: Create a new ASP.NET MVC project using internet template.
step2: Start it and create a new user and login.
step3: Open developer tools check the cookie section you can see two cookies
__RequestVerificationToken
.ASPXAUTH
.ASPXAUTH is the cookie that FormAuthentication consume to do the authentication. For all following requests to the server, the server will check this cookie to authenticate user.
You can specify "Remember me" when you login which will changes the life span of this cookie, if you don't tick it the life span is tied up to current session, if you tick it depends on the settings on the server side.
I am being tasked with writing an asp.net web app that will use ADFS for authentication. However, at one stage in the application users will have to re-authenticate and supply their username and password again.
Can this be done with ADFS?
The ASP.NET app can be an active client to the STS as well as a passive one. When you need to step up, provide some input fields and ask the user for additional proof of who they are. Using the WSTrustChannelFactory, pass this info (and possibly the original token) to the STS to get a new token that is fresher and contains claims that are sufficient to authorize the the higher value transaction.
What is the goal of the re-authentication, i.e., what does the user need to prove?
I'm presuming the application wants a sign-in token with a recent authentication timestamp (within, say, the last 10 seconds), so that the application is reasonably sure that the client system is really still under that same user's control.
(Watch out for clock differences between your web server and your AD FS server, by the way.)
In the coming months I will be investigating a similar scenario, and my current idea is to use the SessionAuthenticationModule.SessionSecurityTokenReceived Event, as described in this blog post by Vittorio Bertocci. However, that cannot be the entire solution, since this only forces AD FS to give out a token, but it does not force AD FS to give out a token with a recent authentication timestamp.
So no answer yet, but perhaps these hints help.
This article describes a "step-up" procedure that might help you in this scenario. I haven't used it though, so I can't comment in detail. It looks very close to what you are trying to do.
Reducing TokenLifetime property makes you to re-authenticate users. suppose by TokenLifetime is by default is 60 min but it shows popup before 20 mins. but there may be data loss
For ASP.NET using WIF, you are using WS-Federation as the protocol to interact with ADFS and get a token. Within this, you can specify wrefresh=0 in the sign-in request to ADFS. When this is sent, ADFS ignores any prior cookie state (web SSO) and does a fresh authentication and so a new token will be issued to the app. In the case of intranet domain joined machine case, this will be silent.
To have user interaction, you can do one of 2 things
For 2012R2, I recommend that you use MFA and the app can request MFA by requesting for MFA in this 'step-up' scenario. See http://blogs.msdn.com/b/ramical/archive/2014/02/18/under-the-hood-tour-on-multi-factor-authentication-in-ad-fs-part-2-mfa-aware-relying-parties.aspx
Outside of this, you can also force username/password auth and combine it with wrefresh=0. This ensures that prior SSO state is ignored and U/P auth is performed.
Thanks
//Sam (#MrADFS)