Resolving attributes from a SAML proxy

Wessel, Keith kwessel at illinois.edu
Wed Oct 6 19:44:47 UTC 2021


Thanks, Scott and Mike.

I've been eyeing the attribute registry and need to recreate the custom attributes in our IdP into that so I can clean up a bunch of my attribute resolver. I'm trying to not mix both the registry and the definitions in the resolver at this point. The example on the web page that Mike referenced gives me a huge jump on how to do that. And it sounds like it'd be simpler to just do that for the one attribute Im trying to add. If I did still want to define it in the attribute resolver instead, that would work, too, correct? Would I just make it of type "simple" and list my subject data connector as the input data connector for the attribute definition?

Yes, I know I can save myself a lot of work by just creating it in the attribute registry.

Thanks,
Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, October 6, 2021 2:37 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Resolving attributes from a SAML proxy

Basically, what Mike said, but I will elaborate a little.

On 10/6/21, 3:04 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    The reference section is empty.

It's not, but the tabs are apparently not accessible if you're not getting that content. It is slow though, so it's also possible you're jumping the gun too. Either way, Rod is I think proposing we abandon the tabs, but that's going to take a while. It is very hard to come up with a way to concisely document the volume of settings.

> Now, I want to retrieve an additional attribute from the upstream IdP, 
> and it's not one currently defined in my attribute resolver. It's a Microsoft-esque attribute.

That means the IdP has no way to decode it, because there are no built-in mapping rules for that in the transcoding rulesets. I'm probably going to correct that at some point, I talked with Chris Phillips once or twice about that, but either way...they don't exist so you have to create them or the IdP has no way to decode them and will just drop them on the floor. Same as the SP does with unknown attributes.

> I know I can pull the attributes back using the subjectDataConnector. 
> I see I can supply a list of attributes to retrieve. Should those be 
> friendly names or SAML2 attribute names in that list? I'm referring to the exportAttributes attribute to this data connector element.

That's the other direction. You have to import (i.e. decode) them before you can export them. The export option controls which IdPAttributes produced by the DataConnector are auto-surfaced without having to create a whole set of AttributeDefinitions for them.

>    I also see that I need to add the attribute to my attribute filter config to allow the ADFS IdP to assert it.

That too, yes.

>    DO I also need to add an attribute definition so that I can use the 
> attribute elsewhere in the IdP, resolving it and doing things like... 
> oh, I don't know... deciding if the upstread IdP performed MFA so I can release the right ACR value?

That's what the export option does. It avoids the extra work of creating those AttributeDefinitions, but the only way this works is if they were decoded into IdPAttributes out of the SAML assertion to start with. That's what ends up in the Java Subject, not SAML Attributes. We turn them into portable/neutral things.

The "ugly" way to make the decoding step happen is to leverage the fact that if you were to create an AttributeDefinition called "foo" with an AttributeEncoder that encoded foo into the Microsoft claim name, the backward compat support will kick in and auto-generate a decoding rule that will turn the Microsoft claim into "foo" internally. That works, but at the cost of the extra AttributeDefinition in a weird place that's kind of confusing. That is why I started from scratch and created the new registry concept to express the rules. Proxying is what made that clearly needed.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!v7l1RF7VvmuPponS57AtJRmY7ssHJSiF5WjjQPK16Ndr5VjISjOImTuIApU-aqGtKA$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list