OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] safe value for AuthenticationInstant?

Note also that there can be some privacy reasons to restrict
the granularity of the timestamp in the AuthenticationInstant
to something where it is likely that a non-trivial number of
users would have the same instant (so the instant itself 
is not a user identifiable piece of information). 

So, NOT using microsecond timestamps is probably a good 
thing to do (I would recommend second, 5 second or perhaps
even 30 second intervals -- this little bit of inaccuracy
probably would not matter in any implementation that is 
knows it has to deal with the fact that system clocks 
are off a bit anyway).


> -----Original Message-----
> From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] 
> Sent: Monday, December 12, 2005 12:59 PM
> To: william; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] safe value for AuthenticationInstant?
> Our product sets to the AuthenticationInstant to the actual 
> time that the user authenticated at the IdP using the method 
> reflected in the assertion sent back to the SP.
> This time would be very important to many SP applications 
> that have strict policies on the freshness of the user's 
> authentication.  If the IdP forces the user to authenticate 
> on every visit to the IdP, then using the current time, I 
> suppose is accurate.  But that's not how most IdP's should 
> work.  If the user had previously authenticated at the IdP 
> due to an earlier interaction with some other SP, then 
> sending an assertion to another SP based on that earlier 
> authentication but using the current time for authn instant 
> is IMO a BAD practice.
> For example, an SP may want to use the authn instant to 
> determine freshness and if outside the bounds of its policy 
> it might send the user back to the IdP with the ForceAuthn flag set.
> Rob Philpott
> Senior Consulting Engineer
> RSA Security Inc.
> Tel: 781-515-7115
> Mobile: 617-510-0893
> Fax: 781-515-7020
> Email: rphilpott@rsasecurity.com
> I-name:  =Rob.Philpott
> > -----Original Message-----
> > From: william [mailto:oasis.saml@javafreelancer.net]
> > Sent: Monday, December 12, 2005 12:17 PM
> > To: saml-dev@lists.oasis-open.org
> > Subject: [saml-dev] safe value for AuthenticationInstant?
> > 
> > i've been perusing the code of an open source 
> implementation of saml 
> > 1.1's web sso profile to try and get a grasp on how saml's being 
> > implemented by other developers out there. here is a comment that 
> > appears in the code at the point where <AuthenticationStatement ... 
> > AuthenticationInstant="..." />  is
> > set:
> > 
> >      "// No one seems to actually care about authn instant so
> >       // we'll just set it to [new java.util.Date()...]
> >       // until there are some other requirements..."
> > 
> > that struck me as a curious comment! i would think that the time a 
> > subject was authenticated is hugely important in most cases 
> (to guard 
> > against replay, for example). how have developers in this 
> forum used 
> > AuthenticationInstant in their projects?
> > 
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on 
> implementing the SAML OASIS Standard. To minimize spam in the 
> archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/saml-dev/
> Committee homepage: http://www.oasis-open.org/committees/security/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]