SAML Assertion Condition NotBefore problem.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SAML Assertion Condition NotBefore problem.

Larry Pardi
I'm having an issue between my IdP and a service provider who is using Oracle Identity Federation and require SAML 1.1 messages.  It appears that our system is a second faster than the Service provider which seems to be causing a problem. 

They sent me a section of their log...

RECEIVER: ERROR: An invalid SAML Response was received: Assertion not yet valid

I looked at the SAML response we are sending:

<saml1:Assertion AssertionID="_45539ef50f4ea9fdc15bc8355defa7c6" IssueInstant="2010-09-28T22:29:17.660Z" Issuer="https://my.server.com/idp/profile/Shibboleth/SSO" MajorVersion="1" MinorVersion="1" xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion">
<saml1:Conditions NotBefore="2010-09-28T22:29:17.660Z" NotOnOrAfter="2010-09-28T22:35:57.660Z">
<saml1:AudienceRestrictionCondition>
<saml1:Audience>https://sso.destination.com/saml/SAMLReceiverService</saml1:Audience>
</saml1:AudienceRestrictionCondition>
</saml1:Conditions>

The IssueInstant and NotBefore are set to the same time.  I've been able to use the assertionLifetime to change the NotOnOrAfter but I can't seem to find anywhere to configure the NotBefore time.  A temporary solution is to set my system clock a few seconds slower and this seems to work but its a domain policy to sync time so I have to keep resetting it.

Is this feature as designed or am I missing something in the documentation or not?

Thanks in advance for the help.

Larry

Reply | Threaded
Open this post in threaded view
|

Re: SAML Assertion Condition NotBefore problem.

Brent Putman


On 9/28/10 6:56 PM, Larry Pardi wrote:
> I'm having an issue between my IdP and a service provider who is using
> Oracle Identity Federation and require SAML 1.1 messages.  It appears
> that our system is a second faster than the Service provider which seems
> to be causing a problem.


Yes.  Long story short - both sides must maintain good clock sync with a
known good time source.  You should check yours and ask them to do the same.

In addition, philosophically and practically it is up to the consumer of
a timestamp to allow for a little clock skew, so as to account for small
clock drifts that naturally occur. (Not just SAML, but also Kerberos,
etc).  Their SP is the consumer in this scenario, so they should
implement clock skew on their side. (Don't know if OIF actually supports
that, but if not, then they need to).


> The IssueInstant and NotBefore are set to the same time.  I've been able
> to use the assertionLifetime to change the NotOnOrAfter but I can't seem
> to find anywhere to configure the NotBefore time.  


Right, you can't.  This corresponds to the "now" time on the server when
the Assertion is created (roughly), and we don't provide any way to adjust.


> A temporary solution
> is to set my system clock a few seconds slower and this seems to work
> but its a domain policy to sync time so I have to keep resetting it.
>
> Is this feature as designed or am I missing something in the
> documentation or not?


It's functioning as designed.  You need to confirm and/or get the clocks
in sync, but to account for the inevitable small drifts (hopefully
seconds, not minutes), it's up to them to implement the tolerance, not
you.  For the record, Shibboleth software (both IdP and SP) supports
clock skew when evaluating timestamps as a consumer.


--Brent
Reply | Threaded
Open this post in threaded view
|

Re: SAML Assertion Condition NotBefore problem.

Bradley Schwoerer
We are running OIF as an SP, and I don't think we have seen this issue,
but we are running the latest version.  I would be interested in which
version of OIF the SP is using.  I am guessing not a recent version.

*If* I can convince our sysadmin to change our clock off of NTP for
testing, I will report back what the 11g version of OIF does in that
situation.


-Bradley


On 9/28/10 6:57 PM, Brent Putman wrote:

>
> On 9/28/10 6:56 PM, Larry Pardi wrote:
>    
>> I'm having an issue between my IdP and a service provider who is using
>> Oracle Identity Federation and require SAML 1.1 messages.  It appears
>> that our system is a second faster than the Service provider which seems
>> to be causing a problem.
>>      
>
> Yes.  Long story short - both sides must maintain good clock sync with a
> known good time source.  You should check yours and ask them to do the same.
>
> In addition, philosophically and practically it is up to the consumer of
> a timestamp to allow for a little clock skew, so as to account for small
> clock drifts that naturally occur. (Not just SAML, but also Kerberos,
> etc).  Their SP is the consumer in this scenario, so they should
> implement clock skew on their side. (Don't know if OIF actually supports
> that, but if not, then they need to).
>
>
>    
>> The IssueInstant and NotBefore are set to the same time.  I've been able
>> to use the assertionLifetime to change the NotOnOrAfter but I can't seem
>> to find anywhere to configure the NotBefore time.
>>      
>
> Right, you can't.  This corresponds to the "now" time on the server when
> the Assertion is created (roughly), and we don't provide any way to adjust.
>
>
>    
>> A temporary solution
>> is to set my system clock a few seconds slower and this seems to work
>> but its a domain policy to sync time so I have to keep resetting it.
>>
>> Is this feature as designed or am I missing something in the
>> documentation or not?
>>      
>
> It's functioning as designed.  You need to confirm and/or get the clocks
> in sync, but to account for the inevitable small drifts (hopefully
> seconds, not minutes), it's up to them to implement the tolerance, not
> you.  For the record, Shibboleth software (both IdP and SP) supports
> clock skew when evaluating timestamps as a consumer.
>
>
> --Brent
>    

Reply | Threaded
Open this post in threaded view
|

Re: SAML Assertion Condition NotBefore problem.

Larry Pardi


On Tue, Sep 28, 2010 at 4:57 PM, Brent Putman <[hidden email]> wrote:
    It's functioning as designed.  You need to confirm and/or get the clocks
    in sync, but to account for the inevitable small drifts (hopefully
    seconds, not minutes), it's up to them to implement the tolerance, not
    you.  For the record, Shibboleth software (both IdP and SP) supports
    clock skew when evaluating timestamps as a consumer.


    --Brent

Thanks Brent, I guess that is where I get confused, in looking at the General SAML 1.1 draft proposal it has a few SAML 1.1 responses which show the notbefore being a few seconds prior to the instance time so I made an ASSumption that the notbefore and notonorafter conditions were there to allow for the mismatch between the sender and receiver.  I also didn't read through all the different drafts so it might have been covered in another draft spec.

I haven't implemented Shibboleth as a service provider yet but were can I read about the settings for handling clock skew?



On Wed, Sep 29, 2010 at 7:33 AM, Bradley Schwoerer <[hidden email]> wrote:
We are running OIF as an SP, and I don't think we have seen this issue, but we are running the latest version.  I would be interested in which version of OIF the SP is using.  I am guessing not a recent version.

*If* I can convince our sysadmin to change our clock off of NTP for testing, I will report back what the 11g version of OIF does in that situation.


-Bradley



Bradley,

My service provider is using 11g in their test environment and 10g in their production since they are in the process of upgrading to 11g.  Shibboleth IdP is working with SAML 1.1 in their 10g instance only (with the clock skew issue) the 11g is not working at all, they tell me that they have found an issue with the way 11g was dealing with the 1.1 response in that it didn't handle name spaces as well as it should.  So when they get the 11g running I'll try to purposely skew my clock to see how 11g handles my responses.


Thanks for both of your responses,

Larry

Reply | Threaded
Open this post in threaded view
|

Re: SAML Assertion Condition NotBefore problem.

Brent Putman


On 9/29/10 9:01 PM, Larry Pardi wrote:


> Thanks Brent, I guess that is where I get confused, in looking at the
> General SAML 1.1 draft proposal it has a few SAML 1.1 responses which
> show the notbefore being a few seconds prior to the instance time so I
> made an ASSumption that the notbefore and notonorafter conditions were
> there to allow for the mismatch between the sender and receiver.  I also
> didn't read through all the different drafts so it might have been
> covered in another draft spec.



Scott may know better, but I don't believe that there is any specific
normative guidance in the SAML spec itself on clock skew issues or how
one should populate NotBefore and NotOnOrAfter fields, either in
Conditions, or in SubjectConfirmationData, or wherever else such
concepts might appear.

It wouldn't be "wrong" to populate the NotBefore a short while in the
past, but then you get into issues of: how much? 3 secs? 10 secs?  1
minute?  If a particular SP's clock is 2 or 3 minutes off, do you set it
back by that much, just because you can?  That might then cause problems
with other SP's, especially since the time window for an Assertion
condition in SSO is usually short in the first place (~ 5 minutes).

The Shib team took a pretty adamant stand that we would wouldn't do
that, both philosophically and practically.  It's up to the consumer to
allow for the tolerance, that's really the only way to avoid chasing
your tail.


>
> I haven't implemented Shibboleth as a service provider yet but were can
> I read about the settings for handling clock skew?
>



The Shib SP's setting is documented here:

https://spaces.internet2.edu/display/SHIB2/NativeSPShibbolethXML



For the Shib IdP, it's only relevant for evaluating the IssueInstant on
protocol messages (we don't consume Assertions), and is handled by the
IssueInstant security policy rule.  Since typically people don't modify
those, we don't have any wiki docs for it, but you can see the bits for
that rule in the custom XML schema used for that rule in
relying-party.xml.  See the 'clockSkew' attribute on the 'IssueInstant'
complex type:

http://svn.middleware.georgetown.edu/view/java-shib-common/branches/REL_1/src/main/resources/schema/shibboleth-2.0-security-policy-saml.xsd?view=markup



--Brent