Shibboleth Developers

["Scott Cantor" <>]

> Basically I want to achieve a system similar to openid simple registration
> protocol. As I read more in SAML 2.0 (and Shibboleth implementation)
> attribute retrieval is more of a back channel operation. This brings me up
> to the second question:

It can be a back-channel operation. It doesn't have to be, and it isn't
normally with SAML 2.0. That's a legacy thing. But I'm sure that still
limits what the data connector API can do at the moment.

> In Shibboleth AttributeQueryProfileHandler implementation the binding that
> is specified is a SOAP binding in handler.xml. I already know that as of
its
> current implementation I can not use httpredirect-post binding but is
there
> any limitation (from specifications point of view) regarding the binding
you
> use for a profile (AttributeQuery in my case for example). If no
limitation
> then I may go ahead and do http-redirect/post binding for AttributeQuery
as
> extension to excellent Shibboleth framework.

The SP won't support it, and nothing you try to interop with today will
support it. It just isn't something that will solve your problem unless
you're intending to control both ends. You can't get people to install
extensions, as a rule, unless you tightly control the community.

> In brief, I want user to submit the attributes using a web form at the
time
> of authentication. Doing this help me obtaining the user's consent as
well.

Which is why I think it's better to do it by proposing changes to the APIs
to allow for front-channel-only connectors only. Or alternatively, as I
said, do it during authentication as part of a custom login handler, and
store the data.

Seems to me, you have to store the data anyway. You can't want to ask for it
every time they login.

> I have looked at some Liberty specifications (ID-WSF, Interaction service
> etc) but IMHO too complex to achieve simple things.

Liberty doesn't really attempt to address this use case. The interaction
service isn't really meant for this.
 
-- Scott