accessing user principal in scripted attributes

[Cantor, Scott]

On 6/15/15, 10:52 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 6/15/15, 10:44 AM, "users on behalf of Liam Hoekenga" <users-bounces at shibboleth.net on behalf of liamr at umich.edu> wrote:
>
>>Maybe I could try a downrev java 8?  I'm pretty sure that 1.8.0-45 is the current version.
>
>I guess anything's possible, given that we don't know what the deal is here. A regression would be one possible explanation, but I'm using 45 on the laptop I ran the unit test on.

I ran a test using a simple script definition accessing the legacy principal name on Java 8 on Linux using both 3.1.1 and the latest 3.2 snapshot, and both of them worked.

With a broken script that references a non-existent context property, the error I get is different:

net.shibboleth.idp.attribute.resolver.ResolutionException: Attribute Definition 'uid': unable to execute script
        at net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition.doAttributeDefinitionResolve(ScriptedAttributeDefinition.java:152)
Caused by: javax.script.ScriptException: ReferenceError: "requestContex" is not defined in <eval> at line number 1
        at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
Caused by: jdk.nashorn.internal.runtime.ECMAException: ReferenceError: "requestContex" is not defined
        at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)

So clearly in your systems, it's populating the script context with a null value.


We should add logging or error handling around that in the plugin, but is there anything unusual about the scenario it's resolving attributes in? Is this just standard post-login get attributes, or something more unusual? During authentication or something like that?

-- Scott