Shibboleth Developers

["Scott Cantor" <>]

> ok, so SPa could get encrypted attribute assertions from the IdP and pass
> them on to SPb via SAML Token Profile. If those attributes are enough to
> grant the user access to SPb then fine, otherwise SPb must use the Subject
> of the assertions, together with SecurityTokenReference to contact the IdP
> and get more attributes.

That's the general idea.

> It just seems more wire efficient passing a Subject and letting SPb do
> it's own attribute work. At the end of the day SPa doesn't care what SPb
> needs and if SPb gets it's own attributes they don't need to be encrypted.

Whether it's more efficient depends a lot on the scenario. In a federated
search, it would require a callback and assertion issued for each database
searched. I've seen people claim federated search itself is a dumb concept
because it's too slow and unreliable. My point isn't to debate these
questions at length, it's just to note that any solution that requires
callbacks will have many detractors, just like the opposite is true.

> I'm not sure I understand what you mean by "signs the token into the
> message". There doesn't seem to be much use in a delegation assertion that
> doesn't have attributes as in most cases SPb will require extra attributes
> over and above what SPa gets. Of course, SPa can never forward SPa
> specific attributes to SPb as it would probably be breaking the IdP's ARP.

It has nothing to do with ARPs, but you can't pull data out of a signed
assertion without breaking the signature.

All I meant was that if you require an application to actually understand
intimate details of the token format to use it in a service call, you'll get
push back. Instead, you just tell the service to attach it and sign it into
the SOAP message.

The WS-Trust model takes this so far as to essentially create a "meta-token"
that bubbles all of the client-relevant details of token use into the
protocol wrapper so that clients can use any token type without actually
understanding it. Servers of course usually need to understand tokens or at
least rely on libraries to do so if they're going to use the data inside
them.

> So is there no way for SPa to communicate to SPb the home location of the
> Subject of the Assertions? Or will SPb know it from it's metadata?

I would think so, why wouldn't it? It's not a question of "home" anyway. I
don't know what the relationship of the subject to the issuer is, and I
don't really need to, but if I want to know where somebody's AA is, I can
find out any number of ways.

> It seems the constrained delegation breaks down when SPa doesn't know the
> full chain of delegation awaiting it. i.e. it does a search at SPb using
> constrained delegation and that causes SPb to search SPc.

That's why I called it "one-hop", as well as why I sketched out what a
generalized token service enabling additional hops would look like. It can
be done, but it's also deeply complex, hard to secure, and steps pretty far
into WS-Trust territory.

But why aren't we just doing Liberty if people want a completely general
solution that's within a year or so of actually being specified? It's a
serious question.

-- Scott