My MFA script is clearing the list of requested attributes
Wessel, Keith
kwessel at illinois.edu
Fri May 26 14:44:52 EDT 2017
Thanks, Scott. But I'm still a bit foggy on this.So because I'm resolving all attributes from the request in the script, they're not being later resolved? From what you said, the later resolution should be unphased by my script even though I'm unnecessarily resolving everything. Which way is it?
And if I do just want to resolve the single attribute, can you point me to a code snippet to accomplish that? I assume I still initialize an attribute resolution context and set the principal, but my call to resCtx.getRequestedIdPAttributeNames() would need to change. I assume I need to initialize a blank collection of attribute names that I can then call add or set on.
Am I close?
Keith
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, May 26, 2017 1:05 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: My MFA script is clearing the list of requested attributes
On 5/26/17, 1:27 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> I've got the following code in my MFA configuration that, when executed, seems to be clearing the list of requested attributes.
> That is to say that, after it executes, no attributes are getting returned to the SP after successful authentication. Obviously, and
> using a basis of the example shipped with the IdP, this is getting the attribute that tells which methods a user is allowed to use.
This isn't really related to the attributes that get returned to the SP. It's an "extra" resolution step to drive your logic but the IdP will still run the resolver afterward as normal. With caching of connectors, it's possible to add efficiencies, but they are separate resolution steps.
> The issue might be this line later in the script, that has a comment about cleanup:
It's related, but the real reason is that the attributes are never transferred from the AttributeResolutionContext into an AttributeContext, which is where the system looks for them later.
If you really want to do it, it is possible to preserve them, but the general intent of the example was that you would explicitly resolve one attribute needed for the rules to work, and not the whole set of connectors and attributes that normally run.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list