Removing a value from an attribute in a script
Wessel, Keith
kwessel at illinois.edu
Wed May 24 18:28:31 EDT 2017
I should have been clearer. There's only one attribute definition at play here, my assurance attribute. Yes, it has dependencies on things like group memberships and the like, but that's it. Really, I was just trying to keep my logic cleaner. As it is now, the first thing I do is always add the password context. Then, if the user is Duo authorized I add the MFA context. I was then going to remove the Password context if I wanted to force MFA.
Now that I write it out, that's kind of stupid, actually. I'll just wrap some logic around the current always-add-password-context part to make exceptions when I want to force MFA.
Thanks for the reality check,
Keith
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, May 24, 2017 5:22 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Removing a value from an attribute in a script
On 5/24/17, 6:00 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> Anyway, is there a simple way to remove an attribute value from an attribute using the Nash scripting engine's allowed syntax in
> IdP v3? I was hoping for a removeValue or remove method, but that doesn't seem to work. Do I have to clear the list then add
> back what I want to have left?
Well, conceptually this is kind of a bad idea because I think to do this, by definition you're inside *another* attribute definition and trying to modify one of its dependencies. Otherwise this makes no sense because if you were inside a script building the attribute you wanted to modify then you obviously have control over this.
And you have a real ambiguity if you start changing attributes like this because now the value set will depend on the sequence of graph nodes in the resolver, and I think it's just not a good idea.
That said, I'm still on Rhino and I have only limited understanding of all the pieces, but I was just looking at the docs on this for something I'm working on, and I think what you want is the getNativeAttribute() call because that directly exposes the underlying IdPAttribute and its values. If you use the wrapped ScriptedAttribute the dependent attributes end up inside, that's a copy of the original values so it can't be modified.
Anyway, I wouldn't do it. If you need to do this, create a second attribute definition layered on the first.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list