Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The ScriptedAttribute attribute definition constructs an output attribute via the execution of a JSR-223 script.

...

  • A package named edu.internet2.middleware.shibboleth.common.attribute.provider is available, and specifically within it, the BasicAttribute class. This provides a facsimile of the V2-equivalent class. Specifically:
    • A constructor which takes a String, being the name of the attribute being created.
    • The getValues() method which returns the current values.
    • This would only be of use in rhino scripting. see below
  • A variable named requestContext  which implements all the methods implemented by the V2 class "edu.internet2.middleware.shibboleth.common.profile.provider.BaseSAMLProfileRequestContext". However, all but three of these methods do nothing but log an error and (where a return value is required) return a null pointer. The three methods which are implemented are:
    • getPrincipalName to provide identification of the subject.  This should be replaced by resolutionContext.getPrincipal()
    • getPeerEntityId to get the entityId of the attribute recipient.  This should be replaced by resolutionContext.getAttributeRecipientID()
    • getLocalEntityId to get the entityId of the attribute issuer.  This should be replaced by resolutionContext.getAttributeIssuerID()
    In V3, all of this information is also available in the AttributeResolutionContext to eliminate the dependency on the legacy interface.

...

Of course, for new scripts created for V3 alone, this isn't necessary.

Examples

Get eduPersonPrincipalName from LDAP or build one from uid

Variant 1: A "Prescoped" AttributeDefinition resolves existing eduPersonPrincipalName values from LDAP, plus it depends on the "ScriptedAttribute" one to generate missing values. The Script also needs a Dependency on the myLDAP DataConnector in order to have access to existing eduPersonPrincipalName and uid attribute values.
(Note that this variant will generate WARN-level entries in idp-process.log, due to the use of 2 Dependency elements while the specified sourceAttributeID only exists in one of them. That's a known issue with the resolver schema. To avoid the warning from getting logged you can add an entry to your logback.xml for the appropriate class ("net.shibboleth.idp.attribute.resolver.PluginDependencySupport"), setting the level to ERROR.)

...