RE: [saml-dev] SAML, trust and WS.

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

> - The basic thrust of the whitepaper seems to be attribute pull vs.
> push.  If you're going to advocate pull, you're going to have to deal
> with the name identifier issue.

I've done plenty of flow mock-ups involving multiple tiers and I never
needed anything special. Transients simplify things (avoids the need for
encryption), but ultimately anything works. You claim they don't (on other
lists) but without any actual reasoning that I've seen nor accept.

As an example that doesn't involve a browser...

C = desktop client that issues searches via SOAP
IdP = IdP (duh)
SPA = metasearch engine
SPB = repository

1. C sends authenticated AuthnRequest or WST STR or whatever to IdP to get
SAML token

2. IdP returns SAML token containing a transient ID issued for SPA plus some
attributes

3. C sends SOAP request to SPA with SAML token attached (maybe bearer, maybe
not, doesn't matter)

4. SPA determines C access using token

5. SPA sends AuthnRequest or WST STR or whatever to IdP with token from C
attached with WSS

6. IdP recovers identity of C from transient ID and if authz, returns new
SAML token containing a transient for SPB

7. SPA sends SOAP request to SPB with new SAML token attached (probably HoK)

8. SPB extracts NameID from token and sends AttributeQuery to IdP

9. IdP recovers identity of C from transient ID, and maybe returns
attributes

etc.

Works across however many hops you want. The trick is defining the messages
and what goes in the tokens. The identifier part of it is trivial because
only the IdP cares about them, unless you want a more persistent identifier,
which is no different than any other attributes.

-- Scott