ProfileRequestContext accessibility outside flow actions

[Cantor, Scott]

On 8/13/15, 2:03 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:


>
>Yes, that's correct and intentional.
> 

Right, but doing it in Initialize won't happen every request, only at the beginning.

>I think I need to clarify our use case a little more because that's not correct afaict. I need to do the following around every ResolveAttributes action for some subset of authenticated subjects:

Right, and by then it's very likely the client has round-tripped, clearing any request attributes set by the first action in the flow.

>We have ACLs in our directory that allow some principals to see attributes only on their own entry, thus the security context when the pool initializes is not sufficient. We have service principals that are authenticating and we need to be bound in that security context to resolve attributes. I believe our implementation sketch would work beautifully with the patch I suggested.

I don't think so. Did you actually try this? I'd be very confused if it worked.

Now, if you put it into AbstractProfileAction, that's another story...

I can't think of any particular harm in setting a request attribute, but it creates some possible issues with overlap in the scopes in webflow. Since it's the same object in conversation scope as would be in request scope, that should be ok, but obviously is subject to testing.

But I'm pretty sure that's where it would have to go. Nothing else runs consistently at every place in the flow no matter how much the client is in the picture.

Obviously, I made explicit allowances for tunneling the PRC through the External login flow rather than trying to do something more invasive. Another option might be to accomodate this specific need in the resolver layer by doing it in ResolveAttributes itself.

-- Scott