What is the correct AuthnInstant value for a proxy IdP

[Stefan Santesson]

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




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