Support use of dynamic scope in AttributeDefinition
Description
Environment
Activity
All done and documentation updated.
That's what worried me, but the definition has access to the dependencies before they are glommed together (which is done at its behest) so we get to tinker with the attributes and their values.
Thats what the code is saying - I'll see how easy that is in practise....
That'd be the idea, but I wasn't sure "the scope will not be be applied to the scopeFromDependency attribute" would be workable given the layer the values get injected.
This is a nice to have, but it's easily implemented via Scripted, so not that big a deal.
Proposed constraints
You must specify scope or scopeFromDependency
scopeFromDependency can come from either a data connector or an Attribute definition
it must have exactly value.
The scope will be applied to all values of all the other input dependencies
The scope will not be be applied to the scopeFromDependency attribute.
Given that I hope/think we can squeeze this in to 4.1.0
I just realized that's not really gonna work, since it can't know not to include the values from that dependency. I suspect it will be super awkward to prevent that, so probably just a nice idea that doesn't work well in practice.
Allow a Scoped attribute to use a dependent attribute to source the value from which to build the scope.
Use case:
Upstream SAML IdP supports users from multiple domains/scopes and issues a UPN of the form username@example.ac.uk
Use the domain portion of the UPN (example.ac.uk) as the "scope" input rather than a static value (usually idp.scope)
<AttributeDefinition id="eduPersonPrincipalName" xsi:type="Principal" /> <AttributeDefinition id="eduPersonAffiliation" xsi:type="Mapped"> ... </AttributeDefinition> <AttributeDefinition id="eduPersonScopedAffiliation" xsi:type="Scoped" scopeFromDependency="eduPersonPrincipalName"> <InputAttributeDefinition ref="eduPersonPrincipalName" /> <InputAttributeDefinition ref="eduPersonAffiliation" /> </AttributeDefinition>