RE: [security-services] NZ gov use case (SP - IDP (where logon service and Identity Verification Service are hypothetically one and the same)

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

> OK so here goes. I'll put the graphic that goes with this in the Library
> now
> 
> 1) Principal attempts to access resource at SP(SA)
> 
> 2) SP redirects principal's browser to logon at IdP
> 
> 3) SP challenge to principal
> 
> 4) Principal response with High Strength Logon
> 
> 5) The SP directs the Principal to the GOAS website to logon at high-
> strength.

I'm having trouble following all that. Do you really mean that the SP challenges the user in step 3, after redirection to the IdP in step 2? How?

What is GOAS and why is that after the login at the IdP?

> OK, so steps 6, 7, 8 seem to be out of scope for SAML profiles as they
> stand.

Yes, and entirely compatible with it. That's just deployment, not a new spec. If the products don't do it the way you want, I don't think there's anything we can do about that. Don't buy them, I guess.

There may be bits that need clarification (I get the feeling nobody but me understands the attribute stuff in metadata) and we probably do need to go ahead and define a "query extension" for transmission in the AuthnRequest.

But the rest is pretty much just vanilla SSO with attributes, implemented in a flexible way. Things are much uglier when you start dealing with backchannel flows and addressing user consent in that context.

> Steps 1 - 5, 11 look like normal Authn Request/Response.

If you say so, as I said, I didn't follow it very well...

> Now all the while, the SP is hangin' in there after the redirect in Step
> 2, waiting for a response with a full blown assertion chocked full of
> identity attributes

Well, yes, but I wouldn't really phrase it that way. The web is stateless. Apps don't "wait". There may be state at the SP side that is orphaned if the user never comes back, but that's what cleanup threads are for.

-- Scott