we have a question about ticket-granting tickets expiration policy. We are using cas authentication. The TGT expires after 2 hours whereas java session exiperes after 30 minutes.Our problem is that if a user works only using a web application more than two hours and than tries to use another web application, the ticket-granting ticket is expired and so the user must re-login, although he can work in the first web application.
Is there a way to renew ticket-granting ticket while the user is working in the first web application??
Sadly, short of doing some magic, as of CAS 3.4 (when I was looking into a very similar problem) the answer is no.
If you absolutely have to implement this feature, the best idea I've run across (a co-worker came up with it, not me) was to have every page of your apps use Javascript to "ping" your CAS server (a simple AJAX request that doesn't care about the return will work), and implement a custom TGT Expiration Policy that keeps track of the last ping-back and expires the ticket if the last ping was more than X seconds ago. However, this approach requires a considerable amount of hooks into the CAS framework and I would recommend against it. I'd provide code but it has been too long since I really dug into CAS's internals.
Related
If I have a single server with multiple domains, what is the preferred method for implementing a single-sign-on solution on the same domain. I am currently using devise, have a few million cookies in place on separate domains, and am stuck. On top of just implementing SSO, I also need to migrate the various cookies to a central domain. Regarding the various servers, they only have one single page that requires me to show different states depending on whether or not the user is logged in.
I have tried the following:
CORS: pick one domain as the central auth hub. From all other domains make cross domain checks to see if the user is logged in. For migrating cookies, detect if there's a "current_user" object, send it to the client, make a CORS request, sign the user in and kill the token. Works Great! BUT... After building it for 2-3 weeks, it TOTALLY FAILS in IE. Even IE11, I'm noticing the default setting is disabling this behavior.
tried tinkering with the session store at
Rails.application.config.session_store
with no luck.
I am currently experimenting with the following:
JSONP: I have someone right now trying to convert the above to JSONP instead while I try some other options:
Set up a custom OAUTH provider. Like before, it will be the "central domain" if the person is signed in, return to the requested domain with a token from which the users can make requests. https://github.com/songkick/oauth2-provider
Looking at this but it looks outdated? https://github.com/rubycas/rubycas-client. I also get the feeling this could have been a solution if I rolled this out from the get-go, but given how far we are into the project, it's unclear to me how I'd transfer the existing cookies. Also it's unclear if this requires two applications for me to get up and running ( one for client(s), one for auth server)
As I go through each of these possibilities, if anyone has had any experience doing what I'm doing, please do inform me and save me a whole lot of work :)
The best way unless this is a toy app is probably to set up an oauth provider.
We use Doorkeeper with Devise for this and it works great. It will be worth your time to set a little time aside to read through the documentation and watch a talk or two on youtube if you're not already familiar with the strategy but once you understand the core concepts its actually pretty simple to set up with the help of this gem.
There is a quick video run down on http://railscasts.com/episodes/353-oauth-with-doorkeeper
I have two questions about Box's Oauth2 API in a testing environment.
Is it possible to have multiple redirect_URI addresses? I'd like to use one address for production (e.g., https://my_site.com/box_redirects_here), one for ongoing development (http://localhost:8000/box_redirects_here) and one for automatic UI tests (http://localhost:8001/box_redirects_here). As far as I could see, the only way to do that would be to create three different Box applications - is there an easier way? BTW, both Dropbox and Google Drive do support multiple redirect URIs.
I have a set of automatic tests that I'd like to run a few times a day. The challenge I'm facing is that every time I run these tests, my refresh_token is invalidated, and I can't use it again - which means I can't run the same set of tests a few hours later without manually getting a new token. One solution would be to save the refresh token, for example in a file, so I could reuse it across testing sessions. But:
It's really cumbersome.
if different developers are running these tests from different machines with no common file system that doesn't really work.
Again, for whatever reason this doesn't seem to be an issue with Google Drive or with Dropbox.
This is not currently possible, and I agree that would be nice.
Your best option is to save the access/refresh token pair to a file or a database (in the event that there's no common filesystem.) The OAuth2 spec grants implementers wide latitude on how they issue refresh tokens, if they issue them at all (I don't think Dropbox does.) While Box's implementation makes integration testing a bit challenging, I think that it ultimately hews most closely to the spec's recommendations.
For your first question, you might be able to get close to what you want by using the redirect_uri query parameter. Although you won't be able to supply an arbitrary redirect URI, you can give one that has the same base URL as the redirect URI in your app console.
From the OAuth tutorial:
Wildcard redirect_uri values are also accepted in the request as long as the base url matches the URI registered in the application console. A registered redirect_uri of https://www.myboxapp.com can be dynamically redirected to https://www.myboxapp.com/user1234 if passed into the request redirect_uri parameter.
For your second question, John is right - Box invalidates a refresh token after it has been used. Although this can be annoying, it's also more secure.
We are:
Using OAuth for both authorization and authentication
Using the implicit-grant flow (i.e. client-side flow)
Issuing relatively short-lived access tokens (measured in hours, not weeks)
I want to offer a comparable experience to the traditional expiring-cookie policy, where you get a certain amount of time that your credentials will work, but if you stay active on the site that window continually resets. I'm realizing that this is not straightforward in OAuth. Yes, tokens are issued with an expiry time, but most implementations keep that time fixed regardless of activity.
This isn't so weird when issuing extremely long-lived tokens as one does when authorizing an integration (like, say, a Twitter app). But it's weird when using OAuth for user-facing authentication. If we issue a short-lived token and the user goes for a big session on our site, their access may run out abruptly even though they are in the middle of something. Even if we issued a token valid for 24 hours, if the user comes back 23.75 hours later, they're going to get 15 good minutes and then suddenly get kicked off.
I'm trying to figure out how to offer my users a better experience while sticking to OAuth mechanics. So far, my best idea is to change the server-side implementation to update the expiry date on the token on each authenticated request (this only works because our tokens have a server-side component - I don't know how it could work if we went the self-contained token route). And then, to keep the client appraised of the updated expiry time, we'll want to send that back with our response, maybe in a header, or a meta attribute in the JSON object.
This approach seems a little complicated, but workable. Is there a better way? Has anyone else dealt with this issue? Am I nuts for even trying?
My site uses ASP.Net MVC 5.2.2 and ASP.Net Identity 2.1.0. In CookieAuthenticationOptions I set the ExpireTimeSpan to 30 minutes and the security stamp validation interval is set to 2 minutes (so that users will be booted out within two minutes of a call to UserManager.UpdateSecurityStampAsync.
The problem is that if users remain idle for longer than 2 minutes and then click on the Sign Out button, the site fails to log them off. After a bit of sleuthing, I found that in these cases the server returns a new application cookie (the cookie sent to the server was different than the one returned from it). What seems to be happening is that the owin code misses the call to AuthenticationManager.SignOut and goes ahead with the generation of a new application cookie, as it normally would have in cases where the old one is more than two minutes old.
Has anybody else encountered this issue? Any suggestions on how to diagnose and fix?
I am using VS 2013 Update 3, but this issue existed with previous versions of Identity.
UPDATE:
As an experiment, I created a brand new ASP.NET Web Application project with the VS 2013 Update 3 templates and noticed the exact same issue: I logged in and then waited for an amount of time equal to the security stamp validateInterval (by default, 30 minutes). After that I clicked the Log Off link and noticed that, just like in my own project, a) I was not logged out, and b) a new security stamp cookie was issued to me. I had to click the link a second time to be logged out. In fact, I didn't even need to sit idle for 30 minutes: I could keep making requests during that period and the click to the log out button would still fail, as long as it was the first request after the 30-minute interval expired.
This seems to be a bug in the OWIN identity code. Basically, if the first request after the validation interval is a signout request, it fails, because the code that validates and issues a new security stamp does not check if the user has logged out as part of the same request. Log out requests will fail, as long as they are part of a request that would cause the re-issuance of the security stamp -- i.e. the first request that is after validationInterval minutes since issuance of the previous security stamp.
I would appreciate it if somebody could confirm this behavior. You don't have to wait 30 minutes and do not have to create a new project. Just take an existing project that uses Identity, temporarily set the validation interval to something really short (30 seconds or a minute), log in, and ensure that the first request after the interval expires is a click on the Logout button. If this is a bug, you should notice that you are still logged in.
I also experienced the same issue.
I resolved the issue by changing my AuthenticationManager.SignOut to specify an authentication type as follows:
AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie, DefaultAuthenticationTypes.ExternalCookie);
Also, your OWIN components should be on version 3.0.0 (Which should be the case, since you're using Identity 2.1.0)
Researching I found how to change the life of a token by using the powershell command
set-ADFSRelyingPartyTrust-TargetName "your app display name Relying party in ADFS trust"-
TokenLifetime "value in minutes"
My problem is that once time passes I need to log out,I do not know if this is possible, thank you for your help.
The token lifetime and your session lifetime are two different things. If you want automatic log out you can do it by configuring the session cookie lifetime at your relying party:
Windows Identity Foundation - relying party session security token lifetime
Good overview here:
ADFS 2.0 time out and relation between Freshness Value,TokenLifetime and WebSSOLifetime parameters.
Essentially, there are two parameters:
WebSSOLifetime:
This is a server wide setting which applies to all the RP’s (Relying Party).
TokenLifetime:
This is a RP level setting which applies to a particular RP. It will not affect other RP’s configured in the ADFS server.
Key point:
In order to prompt a user to re-authenticate, we require WebSSOLifetime to be lower than the TokenLifetime.
This almost sounds like a duplicate of my question
How to set the timeout properly when federating with the ADFS 2.0
What I had to do was to have a local event handler that deletes the cookie but also make sure that ADFS doesn't automatically renew thr session.