Shibboleth Developers

["Cantor, Scott E." <>]

Some comments after reviewing the slides:

On the IdP side, the most problematic issue is the lack of support for 
specifying attributes (and most particularly individual values) in queries. 
Your model seems to be predicated on "just in time" requests for tickets, 
essentially turning the IdP into a KDC, which I still find 
odd...Kerberos-based delegation directly from the KDC seems much cleaner to 
me.

I don't think that's going to be a small amount of work. Not even clear that 
it can be done without actual core changes that aren't going to happen at 
this point until V3.

Whatever we do, it's critical to me that we don't break the semantic of using 
a fixed SAML attribute name for service tickets, and using information in the 
value to indicate the service identity. That's the "correct" model. But it 
also means more plugins will be needed to handle attribute filtering based on 
non-trivial values.

Regarding the open issues, I do think using Sun APIs is a problem (it would 
probably preclude shipping code in core as opposed to extensions). I think 
your slide is mis-worded, the IdP is certainly not Sun Java only.

I think it would be a fairly bad idea to try layering this on native code, 
and that would completely preclude future integration into the product. 
There's no way the IdP is ever going to come with native code requirements. I 
feel pretty safe in saying that. I also feel safe in saying that this would 
have to work on Windows.
 
Regarding storage, I think it will be necessary to leverage the IdP's 
persistence support for this, because of clustering.

 On the SP side, the goal of dynamic requests for tickets is equally 
problematic, because the SP can't accomplish anything by querying for tickets 
from the original IdP since anything it could have gotten it would have 
originally anyway. Essentially, that approach means standing up a distinct 
Attribute Authority with its own SAML identity for the SP to query. And even 
at that, the SP only knows how to do those queries at session init time. It 
doesn't have any support for doing that mid-session right now. It isn't 
impossible to expose something for that, but it's not there now (nor is there 
anything in Jira asking for it).

I'm strongly against the idea of adding a second Apache module to address 
managing the tickets, but of course, I can't stop you. I would never add such 
a thing to the SP core if that's what you have in mind though. The SP already 
has ample plugin capability to support this without doing it in Apache, not 
to mention that's non-portable to other web servers for no good reason.

Amongst the obvious layers to plug this in, the cleanest would probably be to 
do it inside an AttributeDecoder that understands the SAML syntax for 
tickets, and would internally manage the caching process, and could expose 
attributes that represent the filename of the cache if in fact that's the 
appropriate medium of exchange. Of course, that breaks clustering unless you 
have a shared filesystem, so I'm not sure file caching is the right answer.

As with the IdP (probably more so), anything I ship supports Windows, period. 
Unless it's a feature that just doesn't exist there, in which case I have to 
ship an alternative for the same functionality. It would be very unusual for 
me to agree to add anything that was specific to one platform.

A lot of this is obviously from the perpspective of the core. If it's done as 
an unsupported (by us) add-on, obviously they aren't the core team's 
decisions to make.

-- Scott