RFC extensions to Shibboleth

[Cantor, Scott]

On 9/4/12 10:09 AM, "Andrea Biancini" <andrea.biancini at mib.infn.it> wrote:

>The username+password for linux authentication was our point of start
>because usually Linux systems authenticate users this way.
>However I share with you your concern about the philosophy and general
>architecture of Shibboleth.

Shibboleth has no bias toward passwords. The world and the web has that
bias, of course. I would add that the use of SOAP, in for example ECP, is
primarily useful in that it provides a framework for other authentication
types. But creating interop means you have to decide what mechanisms to
support too.

>One modification we are trying to do to our code, is that of replacing
>the Basic Auth mechanism with the ECP profile (used in different other
>projects in this area on Shibboleth).

I do not support the web profiles for non-web applications, that's not
appropriate. ECP is much easier to support for a client than hacking form
POST and redirect support is, even if you could assume use of basic-auth
in those cases, which isn't really a valid assumption. ECP is at least
generally deployed with basic-auth by necessity.

ECP also addresses discovery. With a typical non-web case you have no way
to do discovery that doesn't involve hacks like assuming things based on
identifiers. With ECP you just build it into the client in as simple or
complex a form as necessary.

>Would you think that using SAML ECP profile we would be able to obtain
>our goal without a significant modification of Shibboleth abstraction
>architecture?

ECP is designed to run with any authentication mechanism provided by the
container, so that is much more appropriate to your use cases. However, I
don't like a PAM mechanism that gets the user's password either.

-- Scott