Re: [Axis2] Role support for Axis2 handlers

Hi David:

> I'm sympathetic to the argument of getting into the habit of doing the
> right thing, but what you're suggesting means we'll repeatedly do role
> processing for all headers in every handler which doesn't seem
> optimal.

I think it works out to pretty much a wash.  The way we do it now, which 
is each handler scanning the headers for what it's interested in (by 
namespace) and then checking that subset for roles (which only happens 
for addressing right now, ugh) ends up being almost the exact same work, 
just done in a slightly different order.  If there are a LOT of headers 
targeted at us which don't match - or a lot of headers in our namespace 
which aren't targeted at us, we could end up wasting a little time, 
which is why a getHeadersToProcess(rolePlayer, namespace) might be good 
as it would cycle through only once.   But I'm guessing the difference 
isn't that critical in most cases.

> So... we could* add a useRolePlayer(RolePlayer rp) to the SOAPHeader
> which would cause all the existing methods to use a once-computed
> subset of the headers until useRolePlayer() is called again (possibly
> with null). Axis2 would set it by default before the handler chain.

Yep, I'd had that exact same thought while doing the role processing 
stuff in Axiom. :)  The only issue I had was whether it was right to 
make the SOAPHeader that "stateful"... but in thinking about it a little 
more I think it's fine, since we're never really going to be passing it 
around outside one node.  (speaking of node, we should also be 
supporting the SOAP 1.2 node attribute....)

Plus to this approach - all accessors automatically respect roles. 
Minus - we have to do the subsetting/filtering each time we have a role 
change... so for instance if a Module wanted to use its own role, we'd 
need to add that one somehow.

I dunno, I think we might want to go for it.

> The only problem I forsee with that I don't know how it would work
> with ws-sec (where presumably the role could be encrypted to begin
> with?)

If Rampart decrypts a header, it needs to start the processing model 
again, at least for that header.  See section 9.4.5 of [1].  So for 
this, we'd either rebuild or just add to the stored subset as necessary.

--Glen

[1] 
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf