[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
That would mean the SP would specify the minimum acceptable = authentication "strength", maximum length of timeout settings, and = complete set of authorize-able users. Then potentially an SA or user = could request "stronger" authentication, shorter timeouts, and/or a = subset of the authorize-able users. Neither the SA nor the user can do = the inverse of any of these. In thinking through how this might work, it seems providing a logical = user experience means not mixing SPs requiring timeouts within the same = session. Today in our real production environment, we have been unable = to mix SP timeouts within the same SSO environment without introducing = user interaction anomalies. This is not a technical limitation, the = anomalies exist even in a perfect environment. Mike -----Original Message----- From: John Kemp [mailto:email@example.com] Sent: Tuesday, October 21, 2003 5:13 PM To: Steve Anderson Cc: firstname.lastname@example.org Subject: Re: [security-services] AI 60 - Dynamic Session Material=20 Steve, Thanks for taking the time to review the document! Comments inline=20 below: On Friday, Oct 17, 2003, at 18:17 US/Eastern, Steve Anderson wrote: > Some comments on the use case/requirement document ... Better late=20 > than never, I suppose ... > > I propose changing the definition of "Idle Time-out" from > > A period of time, after which, if there is no activity by the user=20 > associated > with a session, the session may be considered invalid > > to > > A period of time, during which, if there is no activity by the user=20 > associated > with a session, the session may be considered suspended. > > The wording change at the beginning is just clarification, and I don't = > expect it to be controversial. Not controversial perhaps, but important. I can say that what I meant=20 by "timeout" was actually "timeout value" - ie. a timeout value of 2=20 hours would imply that a session was considered timed-out after a=20 period of exactly 2 hours. Changing "after" to "during" changes the=20 meaning of timeout - I like your definition better, but it may well=20 reflect some changes I need to make to the rest of the document ;) > The wording change at the end may generate a little discussion. I=20 > prefer the notion of suspending the session here, because if the user=20 > re-authenticates successfully, the data associated with the session=20 > before the timeout should still be available. Under the previous=20 > wording, there was no distinction between disposition of the session=20 > during timeout and during logout. I'm certainly open to this... anyone else have something to add? > I would also like to echo some of Mike Beach's comments. I view the=20 > SP as the top of the food chain, as it relates to idle timeout=20 > thresholds. Other links in that 'chain' can shorten the threshold,=20 > but not widen. Can you expand on that view? I'll just say the same thing I said about=20 Mike's earlier comment. I think that for a *local* resource, the SP=20 *is* the SA, but that they may be conceptually separate, implying that=20 at the least the SA and the SP will "agree" on timeout values. For a=20 *shared* session, the SA is almost certain to NOT be physically=20 connected to the SP, but still may be, and the SA will have ultimate=20 responsibility for the timeout values set - an individual SP shouldn't=20 be able to affect the timeout value for a session that is shared with=20 other SPs - one would imagine the SA would have to take responsibility=20 to setting the global session timeout, no? Thanks again, - JohnK To unsubscribe from this mailing list (and be removed from the roster of = the OASIS TC), go to = http://www.oasis-open.org/apps/org/workgroup/security-services/members/le= ave_workgroup.php.