What is the correct AuthnInstant value for a proxy IdP

[Stefan Santesson]

Just after writing this I realise that what I suggested won’t fly in my own implementation.
In my proxy IdP I use a standard Shib V3 IdP to perform the IdP part, while the SP part of the proxy is running as an external Authn servlet.
And I don’t think there is any way I could forward the upstream AuthnInstant value to Shibboleth IdP anyway from the ExternalAuthn servlet.

So I guess every proxy have to decide their own time for AuthnInstant.

Correct me if I’m wrong here.

/Stefan



From:  users <users-bounces at shibboleth.net> on behalf of Stefan Santesson <stefan at aaa-sec.com>
Reply-To:  Shib Users <users at shibboleth.net>
Date:  Monday 9 November 2015 at 00:22
To:  Shib Users <users at shibboleth.net>
Subject:  What is the correct AuthnInstant value for a proxy IdP

I’m using Shibboleth IdP and SP components in a cross-border pilot where several proxy IdP:s are involved.

I need help to figure out what each proxy IdP in the chain should claim as AuthnInstant.


For simplicity say that we have an auth chain with 2 proxy IdP like this:

SP  —> Proxy 1 —> Proxy 2 —> user IdP

Proxy 1 issues an assertion to SP, based on an assertion received by Proxy 2
Proxy 2 issues an assertion to Proxy 1 based on an assertion received from the user IdP.

Then what should Proxy 1 and Proxy 2 claim as AuthnInstant?

Should it attempt to preserve the AuthnInstant value received from the user IdP and forward it down the chain of assertions to the SP, or should they claim the time when they themselves received the proof of authentication.

This is is tricky business, but this example is exactly how the EU cross border identification is setup.


My thinking is. If the AuthnInstant is preserved through the chain, that would be the most honest option, and it would also detect if anyone in this chain is doing an SSO authentication instead of forwarding the request to the user IdP. The SP would then receive the time when the user actually used his credentials.

My fear is that this may break current SP code in some way. There may be some time delays in this chain caused by UI:s for user interaction when crossing country borders, such as giving consent to user data being transfered to a service provider in another country.
Forwarding the AuthnInstant may therefore cause situations where there are many seconds between issue instant and authn instant. Could this cause problems with existing SP softwares that requested ForceAuthn=“true” excepting issueInstant = AuthnInstant with no or tiny time difference?

I would like to preserve the AuthnInstant from the user IdP all the way to the SP, but I’m not sure it will fly.


/Stefan



-- To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151109/0ddfebc3/attachment-0001.html>