I would like to enable extended (virtually forever) authentication for my web/mobile application, similar to how many popular sites operate (e.g. Facebook), virtually never needing to re-log in unless your credentials are changed from another terminal or the session is deliberately ended server-side. I am currently evaluating Apache Shiro. I have not yet been able to find a way to support dropping a cookie with some kind of access token that would be submitted every time the site is revisited so that the user does not need to log in again. Is there a way to do it?
Yes,
You can configure the session cookie's MaxAge:
https://shiro.apache.org/web.html#session_cookie
Using the bean properties of the cookie: https://shiro.apache.org/static/current/apidocs/org/apache/shiro/web/servlet/SimpleCookie.html
I'm not sure I'm following the last bit about access tokens and cookies though.
Typically, using a session cookie is default functionality for web apps running on most Java Servlet containers (this differs once you get into REST API frameworks)
Related
I've successfully used cookies before and I'd like to begin using JWT. My biggest question is how to pass your token to a website during the initial GET operation, for example when a user types your domain into their address bar or clicks on a link from some other website like google.
When using cookies for example, if you type stackoverflow.com into your web browser, the persistent cookie is sent to the website which seamlessly allows your own stackoverflow session to be automatically authorized.
I am aware that I can programatically pass my JWT token via a javascript GET through the HTTP headers but how do you pass the token when a visitor types in your URL into their web browser?
Possible solution #1
My thoughts have been to have javascript code check if 'authorized'. If not, check for a JWT token in local storage. If found, redirect to the same address. The problem of course would be that there is no way to pass the token during a redirect.
Possible solution #2
Similar to above but not issuing a redirect, I would update the current page to reflect the 'authorized' state.
Possible solution #3
Use a permanent cookie containing the JWT token. I am thinking that this 3rd option would be the best. If I did this, there would be no need to pass the JWT via an HTTP header.
I've thought about this for a few days, read up on JWT and here are my conclusions for avoiding JWT in my particular case:
No easy way to authorize a user who opens their browser and types in your website. With cookies, your server immediately knows how to respond to this headerless GET request.
No way to easily change the JWT token signature. All users are immediately affected by such a change, essentially forcing everyone to authenticate again.
No way to easily invalidate a specific JWT token. The best you can do is to maintain and check a banned signature list on the server. This of course would require a centralized or distributed server method almost identical to a cookie session management system. This would force a coupling between the token and the server, no longer stateless as intended by JWT.
SUMMARY
Cookie management requires more server infrastructure but you have much greater session control. State is seamless (in the case of #1 above). You can instantly invalidate state. For example, the user can log out (deleting the session at the server level) or the session can be instantly banned by an administrator by simply deleting the session.
I also see the benefits to JWS:
no need to hit the db or cache system when authorizing.
simple authorization between multiple servers having the secret key.
simple authorization, no session management programming and no db session state storage required.
...but the drawbacks stated previously are too great for my particular needs.
Related to Accessing Third Party Apps After Creating A Session Via API Token and to AWS API credentials with OneLogin SAML and MFA
Since AWS assumeRoleWithSAML temporary security credentials are only valid for one hour and we have a few different roles to assume it would be very annoying for the user to enter the username/password everytime he needs to switch the role or get new credentials because of the short validity. It's totally odd to the web base OneLogin usage, where he is logged in once for the whole day or even week (depending on the policy).
I know how to get a session via API. At least this would reduce the times the user needs to enters username/password to two times. One time in the web, one time on the CLI.
But is there any way to use this session token to generate a SAML assertion via API with this session token instead of submitting username/password to the API endpoint?
I don't want so store the users credentials locally for this. And with MFA enabled this wouldn't work in a seamless way.
While being able to generate a SAML assertion for any user (without the need for MFA and a user/pass) seems like a good workaround, this is unfortunately fraught with security perils.
An API that bypasses the usual authentication effectively gives that endpoint the ability to assume any user in AWS. The "assume user" privilege is locked down pretty tightly in OneLogin, and is not the sort of thing that's given out lightly.
Basically, an API to do this seems dangerous from a security perspective. This might be something we'd consider as part of an oAuth flow (or OpenID Connect resource endpoint) but that'll take some more thinking on our part before we'd implement it.
The only compromise solution I can think of that could be implemented today would be to temporarily cache the users' credentials for a longer period of time in your code. This way they could be reused to generate new SAML assertions for a longer period of time, but would effectively be thrown away after (say) eight hours.
This wouldn't allow for MFA on an app policy, but we are building out the ability to request and verify MFA via API (coming soon) so you could implement MFA in your app (independent of any app policy) once this becomes available.
Obviously the ideal solution would be for AWS to let users' configure the session length, but so far they've been unwilling to allow this.
I'm working on a roll-your-own Federation implementation. There are two RPs. SSO between the RPs does not work (erroneously). I suspect it has to do with the cookie that the STS is creating. The STS is writing a fedauth cookie for itself. From my understanding, it should be writing a Forms Authentication cookie?
When hitting the STS for the second time from the other RP I can see in the ClaimsPrincipal that IsAuthenticated=True, yet the user is prompted to login and not automatically redirected back to the RP.
It's worth noting that SSO did work previously, auto redirect and all, but the RPs on the load balancer couldn't share cookies as it was using the machine key (and no sticky sessions). I fixed this by implementing a custom SessionSecurityTokenHandler that utilizes the certificate (code below). It's at this point that the STS started writing FedAuth cookies and SSO started failing.
The sts token is being written with:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);
Token handler:
var sessionTransforms = new List<CookieTransform>(new CookieTransform[]
{
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(federationConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(federationConfiguration.ServiceCertificate)
});
var sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
federationConfiguration.IdentityConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
The STS writes its own cookie. It POSTs the security token to your application. Your application will typically respond by writing a session authentication cookie, which it will use until it expires (and then it goes back to the STS)
If you work in a web farm then there is an out of the box support for this using WIF configuration :
Of course, the machines in the web farm should then share the same machine key. You can of course use your own mechanism but that seldom makes sense.
Next, each RP should therefore write its own "session" cookie that proves your authentication. If two RP's live in the same domain then they should use a different cookie name.
Scenario:
1) you are implementing a website/webserver that supports SSO (SPNEGO).
2) A client connects to you and provides you a ticket which is valid, so access is granted to the client
Question - At this point, should I implement some mechanism such as a cookie that allows for the client to no longer generate tickets (Storing some value that can be cached client side and used for subsequent calls) ? How long/how many requests can I honor the same spnego token? I tried finding the answer for the second question and could not find an answer.... What is the "MAXLIFE" of a token that you can generate for a SPNEGO token?
The first question/answer clearly depends on your usecase. If you have a website with a browser, a session cookie, e.g. JSESSIONID, is the way to go. If this is some library, it has to support cookies. Thoughly, ticket generation is extremely fast.
Second question: Do not fiddle with the tickets. They cannot be reused and will throw an exception: this is a replay. Pass those tokens to SSPI/GSS-API and throw the context away when the auth is completed. As soon as the server nags you again, create a new context and send a new token.
By default, a ticket is valid for 10 hours in Active Directory but this can be changed by the admin. Use kerbtray.exe on Windows or klist on Unix to see the lifetime of your tickets.
Using OAuth 2 I need to limit user access to permitted resources only, where the connection to the API is made through an ext.js REST proxy. The ext.js proxy takes care of data retrieval and maintaining the model relationships. I haven't found an elegant way to make different calls from the proxy to the backend depending on the user logged in.
I am wondering if the proxy has to be different for each user logged in to my application because each user has their own access token.
Another option would be to make the proxy know about the logged in user during the proxy initialisation process and save this information in a persistent way.
Has anyone solved a similar situation before?
The article gives a detailed explanation on how to use OAuth2 with Sencha Touch.
http://www.sencha.com/blog/meetcha-using-sencha-touch-to-build-a-mobile-app-for-meetup-com/
There are several ways to use OAuth. One uses redirects after the initial authentication (for this you might use an iFrame inside a Sencha login view). The other uses your backend server as an intermediary to the OAuth server that can avoid the iFrame solution but requires more logic on your server.
You can then use a session cookie which will be resent with all HTTP requests including your REST calls. Most back ends support session cookies and so all you need to do then is look up the user ID you stored in the session object as part of your REST API code.
Another option is to set a custom HTTP header in each REST call that requires authentication. To avoid duplicate code, create a derived class from the Sencha proxy class to set the header containing the access token. You can store the access token in a Store or on the Application object or as a static value on the proxy. I've done this for both REST proxy calls and Sencha Direct proxy calls.
AJAX Proxy header property:
http://docs.sencha.com/touch/2.3.1/#!/api/Ext.data.proxy.Ajax-cfg-headers