Skip to main content
[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
Hi Leo,

I quickly checked the RSTR from STS and it has Created/Expires timestamp which is essentially same as the NotBefore/NotOnOrAfter in token. So all your client might need is to call IRequestSecurityTokenResponse.getLifetime() to get the Created/Expires timestamp and compare it with current time before sending token to RP.

RSTR:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
      <ns1:Action xmlns:ns1="http://www.w3.org/2005/08/addressing" soapenv:mustUnderstand="true">
      </ns1:Action>
      <ns2:RelatesTo xmlns:ns2="http://www.w3.org/2005/08/addressing" soapenv:mustUnderstand="false">
      </ns2:RelatesTo>
      <ns3:MessageID xmlns:ns3="http://www.w3.org/2005/08/addressing" soapenv:mustUnderstand="false">
      </ns3:MessageID>
      <ns4:To xmlns:ns4="http://www.w3.org/2005/08/addressing" soapenv:mustUnderstand="true">
      </ns4:To>
      <ns5:Security xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="true">
            <ns6:Created>
               2009-06-12T15:37:23.838Z
            </ns6:Created>
            <ns6:Expires>
               2009-06-19T15:37:23.838Z
            </ns6:Expires>
         </ns6:Timestamp>
      </ns5:Security>
   </soapenv:Header>

.....


<wst:RequestedSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
            <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="urn:uuid:B3E055DE138DDA703E12448210437713824" IssueInstant="2009-06-12T15:37:23.771Z" Issuer="https://cards.bandit-project.org/BanditIdP/services/Trust" MajorVersion="1" MinorVersion="1">
               <saml:Conditions NotBefore="2009-06-12T15:37:23.771Z" NotOnOrAfter="2009-06-19T15:37:23.771Z"/>

.....

</soapenv:Envelope>



On Jun 12, 2009, at 11:12 AM, Leonardo Straniero wrote:

Hi,
thanks for the prompt reply. For sure CardSpace is checking the timestamps
while performing the transaction with the STS.
We were expecting a similar behavior in the Higgins library that performs
the transaction with the STS, so well before the token arrives to the RP.
Instead we not only get the token from the STS, but, when our client
forwards the token to the RP, it is accepted without any warning.
On the client side we are in the situation that the released token has been
issued before the client request (even if this was due to are wrong setting
of the client machine clock!).
Are we missing something or is there a bug in the Higgins code?
We have this behavior both when using Higgins 1.1M4 and 1.1M6.

TIA.
Regards.
Leo.

-----Original Message-----
From: Jeesmon Jacob [mailto:JJacob@xxxxxxxxx]
Sent: venerdì 12 giugno 2009 16.42
To: leonardo.straniero@xxxxxxxxxxxx; Higgins (Trust Framework) Project
developer discussions
Subject: 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/Ba
nditIdP/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

Back to the top