[OTDev] OpenSSO now secure
Luchesar V. ILIEV luchesar.iliev at gmail.comThu Jun 17 13:26:06 CEST 2010
- Previous message: [OTDev] OpenSSO now secure
- Next message: [OTDev] OpenSSO now secure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I was partially doing that at the moment... albeit rather slowly, I have to admit. L. P.S. I'm also intending to put all discussed topics on the wiki. On Thu, Jun 17, 2010 at 14:20, Nina Jeliazkova <nina at acad.bg> wrote: > All, > > Does it make sense to summarize these discussions in the deliverable? > > Regards, > Nina > > Andreas Maunz wrote: >> I also consider token expiration not an issue we should deal with >> currently. >> Also, the timeout of 24hrs may even be raised to e.g. 48hrs. More >> important, it seems, is to incorporate the Logout function into the >> workflow, to invalidate the token after the task has actually finished. >> User tokens may be indeed employed in service-to-service connections, >> when permissions are necessary that the requesting service does not >> have (e.g. retrieving a specific dataset). As mentioned earlier, >> services should generally have user accounts too, akin to any >> service/daemon on a stand-alone computer. >> >> Greetings >> Andreas >> >> >> Luchesar V. ILIEV wrote on 06/17/2010 12:55 PM: >>> I second Nina's opinion on OpenSSO hardly providing any mechanism to >>> implement such token "half-life". On the other hand, we have the >>> following general workflow: >>> >>> 1. User acquires token via client application. >>> 2. Client application uses token with various services. >>> 3. The services use token on behalf of user when necessary. >>> 4. On getting the final results, the client "logouts" the token. >>> >>> Thus, for each user-initiated "computational flow" through the OpenTox >>> services, a "freshly-issued" token will be used. Considering that >>> currently the tokens have 24 hours validity, I find it rather unlikely >>> to have many cases of tokens expiring "in transit". That's why I'd >>> rather consider the token expiration a non-issue, at least for the >>> time being. >>> >>> Of course, it would be somewhat different with people communicating >>> directly through the API with the OT services. Obviously, they will >>> handle the authentication themselves, and thus it's upon them to keep >>> an eye on token validity. Still, if they are proficient enough to use >>> directly the API, that shouldn't be a problem. >>> >>> Further, we could prepare some "best practices" document, which could >>> give suggestions on how to specifically avoid these issues, e.g. >>> always use "fresh tokens", or "don't use tokens that have less than N >>> hours validity, etc. Actually, the "best practices" might be handy for >>> many other things as well: e.g. what is considered "polite" use of the >>> OT infrastructure, that is what needs to be avoided in order not to >>> overload it... >>> >>> Cheers, >>> Luchesar >> _______________________________________________ >> Development mailing list >> Development at opentox.org >> http://www.opentox.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at opentox.org > http://www.opentox.org/mailman/listinfo/development >
- Previous message: [OTDev] OpenSSO now secure
- Next message: [OTDev] OpenSSO now secure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Development mailing list