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

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

> Are there implicit assumptions about how C authenticates to the IdP?

No.

> > 2. IdP returns SAML token containing a transient ID issued for SPA plus
some
> > attributes
> 
> Right, this works because evidently the target SP is known.  (Not true
> in my use case, btw.)

If the IdP doesn't know the SP, then I guess you're dealing with some kind
of user-intermediated push scenario, which is also fine. The transient ID
won't matter because no query back will be possible anyway (no
authentication of the SP).

> 2.5.  User controlling C goes to the coffee shop down the street. 
> (While gone, the transient expires.  Since there is no session at the
> IdP, the flow starts over at step 1.)

So what? You can substitute any of 10 timeouts for that one, and you have
the same result. What's more, until SPA forwards the token along, it doesn't
even matter because to *it* the identifier is valid for the lifetime of the
token itself. This is a non-issue.

> A synchronous request?

Doesn't matter, but SPA can't proceed until it gets a token back.

> Assumes much more functionality at the IdP than is available today. 
> (Our development platform is Shibboleth 1.3, which is built on top of
> SAML 1.1.)

Anything you want to do is going to require new functionality. Sorry, that's
the way it is. But that functionality won't have much to do with
identifiers, and that's my only point.

> A synchronous request?

Are queries synchronous today?

> So where is the SSO in your flow?  If C conducts a search at 8:00am
> and then wishes to conduct another search at 11:00am, where in the
> flow does the second search begin?

Anywhere you want. I didn't even show a flow where the client talks to
anything else, so it's not even in the picture. SSO is just how you start at
step 1 again without reauthenticating.

> If there is no SSO, then could you elaborate on step 1?  What exactly
> do you mean by "C sends authenticated AuthnRequest"?

I mean the same thing we mean today on the web, but the request message is
probably SOAP. I'm not elaborating because user authentication is out of
scope.

> For the sake of discussion, take the IdP out of the picture.  Today,
> is there an installed base of clients authenticating directly to a
> metasearch engine?  Are you re-engineering an existing system or
> building a system from scratch?

Yes, I think this stuff happens today on the web, and no, I don't think
there's real delegation in the security model. We were asked to suggest
security models for such a system that do.

-- Scott