Scripted Attribute resolution and legacy support.

[Rod Widdowson]

I have been working through this and I think I have bottomed out which a
good 90/10 (or even 97/3) solution.

I wrote up the current environment at
https://wiki.shibboleth.net/confluence/x/hoC3 noting a couple of
restrictions or ugliness that the V3 scripts would have compared to the V2.

   - V3 Context navigation is feasible, but ungainly
  -  Adding new values is also even more ungainly than it was in V2.

I then went on to the backwards compatibility issues and you will see my
train of consciousness in https://issues.shibboleth.net/jira/browse/IDP-206
.  Do not go there unless you want to see my reasoning.

I think I am now at the stage of making a proposal.  This is slightly more
radical that we had hoped but it hits a lot of the issues straight off, and
it isn't totally off the wall.

1) Change the name that the scripting sees for the V3 resolution context so
that we make the emulated V2 one available via the old name (done).

2) Implement 3 of the 110 methods on the V2 context and either do not
implement or stub out the other 107.  
    The three methods are getPrincipalName,  getLocalEntityId,
getPeerEntityId.  Note that none of the example scripts use the context so
I'm just guessing here.

3) Provide a helper object to ease (V3) context navigation (basically to go
from a string to a java.lang.Class which can then be fed into the context
navigation code).

4) Add a vestigial
edu.internet2.middleware.shibboleth.common.attribute.provider.BaseAttribute
with one method: Collection<String> getValues. [*]

5) Do not provide the “native” attribute to the script, rather provide an
encapsulating class which adds the following methods:

     - getNativeAttribute() . This is to allow full access to the attribute
for complex cases.  Use of this method is incompatible with any other method
detailed below (this will be policed).

     - addAttributeValue(AttributeValue value) and addStringValue(String):
Convenience methods – I expect that only the latter will be used.  Do we
want a removeStringValue()?

      - Collection<String> getValues() – to provide V2 compatibility (this
collection will *NOT* include Scoped or nonString AttributeValues).

6) Make no effort towards thread safety.  What I mean is that scripts which
explicitly invoke threading deserve all they get.  Of course, having
multiple threads running the same script will work (because the contexts
will be different).

By doing some flag setting and comparison with the underlying attribute we
can make sure that when the script exits, the output attribute gets set to
have the values which were expected - noting that V2 scripts can add and
remove values from getValues().

One open question is that the current API allows modification of attributes
which were dependencies of, but not the output of, the resolver.  Whilst we
cannot stop this continuing to work (via the getNativeAttribute method), I
do not think that we need to provide legacy support for it except for the
slightly odd case from the wiki where the input attribute is also the output
attribute - indeed it is the existence of this script in the wiki which
finally forced me into adding the encapsulating class.

The upshot is that we provide V2 support for all those cases which appear to
be common and/or sensible (and all the wiki examples).  We do not support
the cases where a script dives deep into the V2 structures.  Finally we make
native V3 scripting easier than V2 (which is a twin edged sword of course).

Thoughts?  I'd be particularly interested in responses from people who are
running scripts in production.  Would the above provide what you need and if
not, what are the missing methods and on which classes?

FWIW, the Template Attribute resolver (velocity) presents none of these
issues bar the need for documentation.

Rod

[*] this class represents a difficulty - do we want to put it inside
idp-attribute-resolver-impl (which is a bit ugly) or do we want to give it
its own jar (which is overkill).  Opinions?