Delegation flow: authn and c14n

[Cantor, Scott]

On 9/2/15, 7:41 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:


>
>Yeah, had thought about that, just hadn't tried it yet.  Probably cleaner and doesn't expose the SAML stuff to the outer flow.

Oh, yeah, you definitely want to clean that out (probably by just replacing the context with a new one). Reason being that somebody could add their own c14n flow(s) to the master list for their own purposes and if those trigger off what you leave behind, that would be bad.

It's like a parameter set, in and out, so you're basically bleeding parameters in.

>Don't think I knew about that.  That sounds like what I was after.  I didn't want anything that related to the delegation act of "authentication", such as it is, to be in any way stored for the user's regular tracking of authentication data.

It can't be, due to the session just not being there for the back channel flow, but it's still pointless to save it. We probably want to go farther though and actually skip the IdPSession steps as well, just needs a bit of work.

>Already doing that and it works to select that flow, but it still seems necessary to set the *available* flows via idp.properties.

I figured. I don't think changing that semantic is really a big deal, I just need to think about it a little.

>This flow isn't throwing any obvious errors on that stuff, but I don't know what to look for as far as it doing things it ideally shouldn't.

I think it would break badly if there were a problem, I just need to scan the logs and make sure it's running only what it should.

-- Scott