Shibboleth Developers

["Dharam Veer" <>]

Thanks Chad. Answers (rather questions :) inlined).

On Mon, Oct 27, 2008 at 12:30 AM, Chad La Joie <> wrote:

Well, there isn't any reason you can't use the redirect binding.  The
current handler.xml is set up as it currently is because that's what the
SAML spec currently defines.  If you look at the spec there is nothing
that describes attribute query via front-channel mechanisms and so we
don't ship such a configuration in the example.  

DV> Yes, I noticed that in specifications but just wanted to ask the experts if there is any security concern exchanging attributes like this way. Although I do believe that there should not be any else then Web SSO profile would also be problematic.

 

However, if you don't
mind having a non-standard system you should be able to just attach a
redirect decoder/encoder pair to that profile handler and it should work
okay.

DV > This is new. I have been reading Shibboleth code and entire architecture this weekend (great work guys, you rock !!) but I did not see anywhere attaching
encoder/decoder paris to profile handlers. Only thing I see is specifying the inboundBinding and outboundBinding. I know that in internal.xml there is some configuration which associate encoders/decoders with bindings. Do you mean that just specifiying the binding in handler.xml would take care of it ?

DV > Would appreciate if you could throw some more light on this for me.

 

 Note that attribute statements carried over redirect are likely
to be problematic and run in to web server URL length limitations.

DV > But HTTP POST should be go for that problem. No ?
 

Dharam Veer wrote:
> Thanks Scott.
>
> I tried putting them in a form of cache and then retrieved from the
> DataConnector, it worked but do not like it. Would have preferred mechanism
> similar to the AuthenticationEngine for attribute retrieval also.
>
> 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:
>
> 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.
>
> 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.
>
> I have looked at some Liberty specifications (ID-WSF, Interaction service
> etc) but IMHO too complex to achieve simple things.
>
> Would really appreciate your opinion, time and help on this matter.
>
> Regards & thanks again
> Dharam
>
> On Sun, Oct 26, 2008 at 3:50 PM, Scott Cantor <> wrote:
>
>>> I have been able to understand how to write a custom login handler for
>>> Shibboleth (with lot of hiccups in getting xsd and configuration right
>> :))
>>> and now I am onto the attributes part. As I understood from the
>>> documentation DataConnectors are used to retrieve data from different
>>> sources but in my case user attributes are to be submitted by user using
>> a
>>> web form i.e they are stored in some respository.
>> In general, you would have to do that ahead time, store them, and then
>> retrieve them from the database.
>>
>>> Do I have to write a DataConnector to do it ? I looked in the code how
>>> AttributeResolver is working and could not find a way to write a
>>> dataconnector which is capable of redirecting to a web page to collect
>>> attributes etc ?
>> There isn't. A connector has to handle both push and pull scenarios, and a
>> query wouldn't permit user interaction. That's aside from all the other
>> problems that might come up trying to do this.
>>
>> I suppose eventually it may be useful to offer options for connectors that
>> just wouldn't support pull/query, but I don't think that option exists now.
>>
>> -- Scott
>>
>>
>

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
, http://www.switch.ch