shibboleth-dev - RE: Final Working Draft 01 of HoK Browser SSO
Subject: Shibboleth Developers
List archive
- From: "Josh Howlett" <>
- To: <>
- Cc: "Toshiyuki Kataoka" <>, "Josh Howlett" <>
- Subject: RE: Final Working Draft 01 of HoK Browser SSO
- Date: Wed, 12 Mar 2008 13:51:25 -0000
> However, I'm not sure how bearer artifact works at all
> without doing this. After all, don't the user and the
> session have to be tied to the subsequent artifact query more
> strongly in the case of bearer delivery of artifacts?
> Section 3.6.3 of SAML2Bind mentions this fact, so I think
> it'd be redundant here.
I think the interesting difference is that in the classical artifact
model the SP only authenticates the assertion that it resolves, not the
transport used to deliver the artifact. SAMLBindings 3.6.5.2 (Security
Considerations) states that '[t]he transmission of an artifact to and
from the user agent SHOULD be protected with confidentiality' but makes
no recommendation regarding authentication.
In the HoK artifact model, you MUST authenticate both. Well, I guess you
could authenticate the user-agent *after* the artifact is resolved, but
that would seem to require a slightly different work-flow from that
required by the other bindings.
In short, I had a bunch of classical assumptions that were being
challenged by your profile, hence my confusion!
josh.
> Actually, the use of holder-of-key assertions would probably
> allow a client to "claim" an artifact without persisting
> state, which is possibly useful in load-balanced
> environments. I might say something about that instead. :D
>
> Interesting ideas,
> Nate.
>
> On 12 Mar 2008, at 12:38, Josh Howlett wrote:
>
> > When I first read this, I immediately wondered how the user agent
> > demonstrates to the SP that it possesses the private key associated
> > with the keying information included in the assertion's
> > <saml:SubjectConfirmation> given that the artifact resolution is a
> > direct callback to the IdP.
> >
> > It took me a minute to realise that the SP, of course, can
> > authenticate the connection used to deliver the artifact
> (via the user
> > agent) and persist the relevant TLS state until it resolves the
> > assertion at which point it's done.
>
>
JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
- RE: Final Working Draft 01 of HoK Browser SSO, Josh Howlett, 03/12/2008
- Re: Final Working Draft 01 of HoK Browser SSO, Nate Klingenstein, 03/12/2008
- Message not available
- RE: Final Working Draft 01 of HoK Browser SSO, Josh Howlett, 03/12/2008
- RE: Final Working Draft 01 of HoK Browser SSO, Scott Cantor, 03/12/2008
- RE: Final Working Draft 01 of HoK Browser SSO, Scott Cantor, 03/12/2008
- Message not available
- RE: Final Working Draft 01 of HoK Browser SSO, Josh Howlett, 03/12/2008
- RE: Final Working Draft 01 of HoK Browser SSO, Josh Howlett, 03/12/2008
Archive powered by MHonArc 2.6.16.