[Shib-Users] Having trouble with "Script Attribute Definition" that include attributes with a "-"
Jeffrey Crawford
source attribute has a dash "-" in it. The following attribute resolver
works using "uid" as an attribute source:
=======================================================================
<resolver:AttributeDefinition id="myAttribute" xsi:type="Script"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:switch.ch:attribute-def:myAttribute" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:2.16.840.1.10.1.1.7" friendlyName="myAttribute" />
<Script>
<![CDATA[
// Import Shibboleth attribute provider
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
myAttribute = new BasicAttribute("myAttribute");
// Return the attribute preappending "SC" to the "uid"
myAttribute.getValues().add("SC" + uid.getValues().get(0));
]]>
</Script>
=======================================================================
However if I'm trying to use this code that has an attribute with a dash
in it "attr-withDash" as a source attribute, everything after the "-" is
ignored:
=======================================================================
<resolver:AttributeDefinition id="myAttribute" xsi:type="Script"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:switch.ch:attribute-def:myAttribute" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:2.16.840.1.10.1.1.7" friendlyName="myAttribute" />
<Script>
<![CDATA[
// Import Shibboleth attribute provider
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
myAttribute = new BasicAttribute("myAttribute");
// Return the attribute preappending "SC" to the "attr-withDash"
myAttribute.getValues().add("SC" + attr-withDash.getValues().get(0));
]]>
</Script>
=======================================================================
Basically the error message shows up as the following it only uses the
front end of the attribute "attr" from "attr-withDash"
=======================================================================
16:48:08.776 - ERROR
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ScriptedAttributeDefinition:134]
- ScriptletAttributeDefinition myAttribute unable to execute script
com.sun.phobos.script.util.ExtendedScriptException:
org.mozilla.javascript.EcmaError: ReferenceError: "attr" is not defined.
(<Unknown Source>#7) in <Unknown Source> at line number 7
=======================================================================
Chad La Joie
dash, is that what you meant?
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Jeffrey Crawford
"uid.getValues().get(0)" That is the only way I know of to get the text
value of an attribute. however in the second example I'm trying to get
"attr-withDash.getValues().get(0)" and this is where it seems to break
down. I'm guessing java doesn't like "-" in variable names, but how do I
get the value of an attribute named "attr-withDash" otherwise?
I'm not even sure where these variables are being set, there seems to be
some magic in the "importPackage" statement, so knowing that may help me
get around this issue.
Jeffrey
Chad La Joie
Jeffrey Crawford wrote:
> sort of, the attribute is called in the script section as
> "uid.getValues().get(0)" That is the only way I know of to get the text
> value of an attribute. however in the second example I'm trying to get
> "attr-withDash.getValues().get(0)" and this is where it seems to break
> down. I'm guessing java doesn't like "-" in variable names, but how do I
> get the value of an attribute named "attr-withDash" otherwise?
Well it's not Java its ECMAScript. But right, that language (nor Java)
allows a dash in variable names. So, if you want to use that attribute
you need to rename it to something that doesn't have a dash. That
attribute IDs are only ever used within the IdP, they have NO
correlation to SAML attribute names. So a quick search and replace
should fix it.
> I'm not even sure where these variables are being set, there seems to be
> some magic in the "importPackage" statement, so knowing that may help me
> get around this issue.
I'm not sure what magic there is, it's just an import statement, like
Java's import keyword.
Jeffrey Crawford
about search and replacing attribute names somewhere externally? If
there is a way to do search and replace within the script do you know of
an example anywhere. After a short search I wasn't able to see a way to
get a list of variables listed/changed or anything like that. Although
I'm just starting to look into this and may be looking in the wrong places.
Jeffrey
Chad La Joie
Just change the ID of that particular attribute to something without a
dash (perhaps use an underscore). So, do the search and replace within
attribute-resolver.xml and attribute-filter.xml
Jeffrey Crawford wrote:
> Do you mean search and replace within the Script, or are you talking
> about search and replacing attribute names somewhere externally? If
> there is a way to do search and replace within the script do you know of
> an example anywhere. After a short search I wasn't able to see a way to
> get a list of variables listed/changed or anything like that. Although
> I'm just starting to look into this and may be looking in the wrong places.
--
Jeffrey Crawford
from the bottom of page
"https://spaces.internet2.edu/display/SHIB2/ResolverScriptAttributeDefinition"
which states the following:
A variable for each attribute produced by the defined dependencies of
this definition. The variable's name will be that of the ID of the
attribute from the dependency. In the event that more than one
dependency produces attributes with the same ID the values of all of
those attributes will be merged and made available to the script.
basically I have an LDAP attribute called something with a dash in it,
lets say the LDAP attribute is "alt-uid" and I want to reference that
attribute with a dash in a new attribute via a statement like:
myNewAttr = new BasicAttribute("myNewAttr");
myNewAttr.getValues.add("PreText" + alt-uid.getValues().get(0));
notice that the part of the above statement alt-uid.getValues().get(0)
is where I'm having the issue. the variable "alt-uid" is invalid via
variable naming rules. In the case I'm talking about the
attribute-filter.xml will only have a reference to the "myNewAttr"
attribute which does not contain the dash.
Sorry to keep hounding but I'm not clear as to how I can rename the
"alt-uid" variable.
Jeffrey
Chad La Joie
creating using an attribute definition. Alright, so it's coming from
LDAP with a hyphen in it. So what you need to do is basically an
attribute rename. You do this with the Simple attribute definition,
like so.
So, you should do something like this:
<resolver:AttributeDefinition xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="altUID"
sourceAttributeI="alt-uid">
<resolver:Dependency ref="myLDAP" />
</resolver:AttributeDefinition>
Then in your Scriptlet attribute definition add (in addition to the LDAP
dependency) the above attribute definition. And then use the variable
"attributeNameWithDash". So you'll end up with this:
<resolver:AttributeDefinition id="myAttribute" xsi:type="Script"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:Dependency ref="myLDAP" />
<resolver:Dependency ref="altUID" />
<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:switch.ch:attribute-def:myAttribute" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:2.16.840.1.10.1.1.7" friendlyName="myAttribute" />
<Script>
<![CDATA[
// Import Shibboleth attribute provider
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
myAttribute = new BasicAttribute("myAttribute");
// Return the attribute preappending "SC" to the "uid"
myAttribute.getValues().add("SC" + altUID.getValues().get(0));
]]>
</Script>
--
Brent Putman
Jeffrey Crawford wrote:
> Sorry not trying to be thick but I'm confused, the rule I'm using is
> from the bottom of page
> "https://spaces.internet2.edu/display/SHIB2/ResolverScriptAttributeDefinition"
> which states the following:
>
> A variable for each attribute produced by the defined dependencies of
> this definition. The variable's name will be that of the ID of the
> attribute from the dependency. In the event that more than one
> dependency produces attributes with the same ID the values of all of
> those attributes will be merged and made available to the script.
Yeah, that's right. The problem however is that the raw attribute name
from the data source and automatically made available by the data
connector has a character that isn't a legal variable name.
One could argue that this is a minor bug and we should have some
automatic handling of illegal characters, either report an error or make
some standard transformation to convert the name (which might be
impossible, since the different scripting languages probably have
different rules as to legal identifier characters). However there is a
workaround, so maybe not worth it...
>
> Sorry to keep hounding but I'm not clear as to how I can rename the
> "alt-uid" variable.
What you need to do is logically rename the attribute using another
AttributeDefinition, and then make that the dependency of the Script
definition, rather than the LDAP connector directly (unless you need
other attributes from the latter, in which case both should be listed as
a Dependency).
I think (but can't test at the moment) that you can do simply with a
Simple attribute def, by using the sourceAttributeID to rename, like so:
<resolver:AttributeDefinition xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="altuid" sourceAttributeID="alt-uid" dependencyOnly="true">
<resolver:Dependency ref="myLDAP" />
</resolver:AttributeDefinition>
Note: If you want to additionally release that attribute from the
resolver as-is, then you'd need to remove the dependencyOnly flag and
add encoders.
And then declare the Dependency in your Script to be on "altuid" instead
of (or in addition to) "myLDAP'". Then you should be able to use the
automatically exported variable "altuid" in your script.
--Brent
Chad La Joie
face, some of the supported scripting languages support hyphens in the
name. For example, in Groovy you could do this:
"alt-uid".getValues.get(0)
I think you can do something similar with Ruby (using symbols) and
Python as well.
Brent Putman wrote:
> One could argue that this is a minor bug and we should have some
> automatic handling of illegal characters, either report an error or make
> some standard transformation to convert the name (which might be
> impossible, since the different scripting languages probably have
> different rules as to legal identifier characters). However there is a
> workaround, so maybe not worth it...
Brent Putman
languages vary. Of course... since we know what language the script is
in... based on the Script element... (wait for it)... we could
theoretically have a name validation rule for each language, and run the
appropriate one. I'll get right on that...
Seriously, probably easier to just document that any effective attribute
dependencies must have names which are legal variable names in the
language to be used, and note the mechanism for the logical rename.
Chad La Joie
Brent Putman wrote:
> Yes, I know, and I agree, it would be really hard, because all the
> languages vary. Of course... since we know what language the script is
> in... based on the Script element... (wait for it)... we could
> theoretically have a name validation rule for each language, and run the
> appropriate one. I'll get right on that...
.... yeah... you do that. ;) Actually this would be a problem since
people can plug in all sorts of script engines and getting them to write
validators or transformers would be a huge nightmares.
> Seriously, probably easier to just document that any effective attribute
> dependencies must have names which are legal variable names in the
> language to be used, and note the mechanism for the logical rename.
Yeah, I can do that, I'm in the Wiki now.