[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [higgins-dev] Mismatch between the issue and receive token time due to wrong time zone setting
|
Looks like cardspace is checking IssueInstant/NotBefore/NotOnAfter in
SAML Token against the current time and not doing something in the
SOAP interaction with STS.
<saml:Assertion AssertionID="urn:uuid:
3F7D3436A5A6CBF4121242660513281963"
IssueInstant="2009-05-18T15:28:33.281Z"
Issuer="https://ip-bancaire.atosworldline.bancaire.test.fc2consortium.org/BanditIdP/services/Trust
"
MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion
">
<saml:Conditions NotBefore="2009-05-18T15:28:33.281Z"
NotOnOrAfter="2009-05-25T15:28:33.281Z" />
......
</Saml:Assertion>
I know most of the RP libs check for validity of the token by
comparing current time with NotBefore and NotOnOrAfter
-Jeesmon
On Jun 12, 2009, at 9:29 AM, Leonardo Straniero wrote:
Hi All,
During a travel that led to the change of time zone, I accidentally
forgot to change the time zone settings of my computer.
I have two application (which use Higgins 1.1M6 code):
· The JCUAL: this application send a request to the Higgins
Selector Switch and use Microsoft CardSpace; there is an end user
that select an I-Card to interact with my Bandit IdP. When I perform
a token request, MS Cardspace doesn’t conclude the operation and
exits with the following fatal error (I read this error in the
Windows’ EventViewer):
The security timestamp is stale because its creation time
('12/06/2009 8.14.39') is too far back in the past. Current time is
'12/06/2009 9.14.39', maximum timestamp lifetime is '00:05:00' and
allowed clock skew is '00:05:00'
This means that the MS Cardspace provide a check between the Issue
and receive token time with a tolerance of five minutes.
· The JCAL: in particular to make possible the use of
Higgins between a Java/C++ server application (acting as RP) and non-
interactive Java/C++ clients (i.e. applications that do not interact
with end users to select cards, etc.). For us an application that
needs to authenticate to an RP providing an authentication token
obtained from an STS is a "client application". In this application,
If I voluntarily replicate the time zone mismatch scenario, the
Higgins 1.1M6 code doesn’t intercept this bad situation. Is in the
Higgins Framework provided a similar check in the SOAP interaction
with the STS?
Any feedbacks will be appreciated.
TIA.
Best regards.
============================
Dr. Leonardo Straniero
CRS - Corporate Research
<image001.gif>
c/o Tecnopolis N.O.
Strada Prov. per Casamassima Km 3
70010 Valenzano (BA) - Italy
<ATT00001.c>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature