RE: [saml-dev] SubjectConfirmation in SAML query

["Scott Cantor" <cantor.2@osu.edu>]

> I read the overview.

That isn't going to help you very much. I'm talking about the raw specs, not
the profile service. That's just an application of WSF.

> It talked about storing attributes at what are
> effectively SPs and those SPs acting as proxy Attribute Authorities. So
> you can end up with your personal profile all over the place.

Centralizing everything at one IdP isn't realistic either, but the overview
talks about only specific applications of WSF like profile services, not the
framework itself.

> It also seemed to rely on a user in it's scenarios. I couldn't see any
> federated machine to machine, n-tier solutions. But I just had a quick
> skim so maybe I missed something.

The whole point of WSF is for n-tier, machine to machine, federated
security. You couldn't define it better if you tried.

> Bouncing attribute release decisions off the user in an n-tier hierarchy
> would be pretty messy for the user. Federated search is a use case I have
> just now. Each search service requires attributes, in the background,
> without bothering the user. So they should all go and get their own
> attributes, with SP1, the aggregating search SP, giving them enough
> information to:

WSF can support federated search just fine. Those SPs don't need to do
anything but consume tokens given to them by SP1 which it obtains in real
time from the IdP.
 
> I haven't seen anything that addresses n-tier that isn't complicated. Come
> to thik of it I haven't seen any, full stop!

I've mentioned it dozens of times. You may not agree with me on what a
suitable solution is, but that's life I guess.

> can you expand on that? what shared identifier are you talking about?

If you expect SP2 to ask for the data (and I think that's the wrong
approach), it has to be able to ask for attributes from the IdP using a
shared identifier of some sort. Pushing a token from the original SP doesn't
require that. The token just contains a transient ID because the SP can
request that from the IdP when it asks for a token to use at SPn.

It's a relatively simple flow.

User does SSO to SP1 using Token1.
SP1 sends AuthnRequest to IdP secured by Token1 and asks for new token for
SP2.
SP1 sends application request to SP2 secured by Token2.

For federated search, you can determine the SPs you want to use, combine all
the requests into one AuthnRequest in step 2 and get back one multiply
encrypted token, or multiple tokens.

You can also use WS-Trust for the middle step, just not interoperably at the
moment.

-- Scott