Shibboleth Developers

["Scott Cantor" <>]

> a) What is the key driver for choosing between Browser/POST 
> Vs Browser/Artifact ?

Artifact can be faster, but it also requires some degree of back-end state
across an IdP cluster. SAML 2.0 makes dealing with that easier, but still
requires a lot of set up of distinctly named retrieval endpoints to take
advantage of the help.

POST has some drawbacks with regard to non-Javascript environments and
back-button issues, but seems to be increasingly viewed as a usable binding
across a lot of non-SAML systems, which makes me think it's the better
choice going forward.

Also until 2.0, the attributes are in the clear in the form, which is why
Shibboleth used the backchannel query instead of pushing attributes,
although that option is now supported too.

My personal preference is for POST + push with encryption, and I lean toward
making that the default option in 2.0. Nobody has really offered an
alternate view yet.

In most Shibboleth delpoyments today, basically POST + query is the default
and usually only supported option in order to allow use of Shibboleth 1.2,
WAYFs, etc. The other options are for experimentation, specialized cases, or
commercial interop.

> b) From the documentation it looks like for Browser/Artifact 
> there seems to be an additional network call from ACS (SP 
> side)  to  ARS (IDP side) before authenticating the user to 
> retrieve reference to SAML assertion. Does this mean 
> Browser/post has advantage over Artifact in terms of  turn 
> around time for authentication ? Is this understanding Correct ?

POST requires signing a message, which is much slower than TLS is, so
generally I think POST is slower, but without push, it's always slower
because we do the backchannel too.

Of course artifact can also be done with signing, but that's not how it's
usually deployed.

> c)Now in both cases will the SP make default call to IDP for 
> retrieving attributes for authorization while using 
> Browser/POST profile?

That's a push vs pull question. Until 1.3 push was not an option.

> This seems to be happening in the java sample posted in 
> http://shibboleth.internet2.edu/downloads/JavaSP/shibboleth_ec
> lipse.htm

Please ignore any and all Java SP documents and code.

-- Scott