Shibboleth Developers

At 8:34 PM -0400 4/5/09, 

 wrote:
> 4) Discussion items
> 	-- attribute aggregation, a rising chorus of requests, some 
> discussion re possible approaches

I'd also like to spend some time discussing teh IdP mods necessary to 
support the n-tier project.

During the last call, we talked about starting with a minimal 
implementation, which could be a throwaway but would be sufficient to 
allow Adam from Unicom to continue with his testing. Here's some 
notes from Scott describing talking about a starting point:

At 11:15 PM -0400 4/2/09, Scott Cantor wrote:
> I'm not sure what level of detail you're looking for, but if this is for
> Jim, the starting point would have to be looking at the wiki pages with the
> sequences and examples to understand what we're trying to build.
>
> Then I guess what we're looking for is a throw-away profile handler to
> simulate some part of the SOAP endpoint at the IdP that handles steps
> 2.4-2.6 of the
> https://spaces.internet2.edu/display/ShibuPortal/Solution+Proposal topic.
>
> The examples there should give some idea of what's involved.
>
> I think what we're looking for is just to be able to scan over the input to
> see if it looks correct (the more checking it does, the better to help Adam
> debug his request), and then either simulate a response, or implement some
> kind of rudimentary prototype of one.
>
> A simulated response would probably just hardcode the user identity, but
> probably could still invoke the attribute resolver "for real" to generate
> the attributes to return. Or a prototype could in theory run the subject of
> the assertion in the SOAP header through the usual logic we use in the
> resolver to reverse map the SAML NameID into the user identity, just like
> with attribute queries.