Referencing entity attributes in the terms of use key bean

[Wessel, Keith]

Thanks, Scott! This helps a lot and was pretty much what I was expecting. It parallels the in-line script for the checkSecondFactor bean in the MFA configuration. So, I think I'm now in familiar territory.

Thanks for the clarification and for kindly steering me away from what would have been a frustrating dead-end with the com.google.common.base.Functions Class. Yes, you're correct, I was getting that from the coded example, and I now see what that's doing and why that doesn't apply here.

And as for dozens of orgs... yeah, it would have been nice if we didn't have so many. There was even talk of an enterprise-wide SSO config for our Github contract which Github supports, but that would involve everyone being willing/able to use SSO for their Github accounts. Ah, the joys of decentralized IT. I'll leave out the rest of this rant as it's (1) not polite to publicly grumble about my institution that is, for the most part, pretty on their game, (2) off-topic, and (3) the weekend and there are better things to do.

Thanks again,
Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, September 11, 2020 3:58 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Referencing entity attributes in the terms of use key bean

On 9/11/20, 4:30 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

> And Scott, unfortunately, I can't go with a regex because, of course, the powers that be only want this applying to
> Github orgs used for courses, not for everything.

I was assuming like "10" GitHub orgs, not hundreds with different rules.

>    What should the class attribute be for the shibboleth.consent.terms-of-use.Key bean definition? Could it it still use
> com.google.common.base.Functions? Or should I use something more like the scripted beans in the MFA configuration?

The bean needs to support java.util.function.Function with the right input and output types, that's the only requirement.

There's no method you can call on com.google.common.base.Functions that's going to do anything useful for you. I assume the only reason you asked is that it's used in an example that happens to use the forMap method to demonstrate a tricky way to remap values, string into string. That's not relevant to anything but the trick it's demonstrating, and that's not your use case.

If you want to use a script, then you want to inherit from shibboleth.ContextFunctions.Scripted since the input type here is ProfileRequestContext.

You can just as well define a class in Java that implements Function and deploy it in a jar.

>  I understand that I need to use the predicate to check if the entity attribute tag/value match certain specified values
> (and yes, Scott, you're correct that I don't need to pull out the value to use it, just match against it). I should put that
> predicate inside my scripted function, using an if statement to compare the tag and value to the expected values,
> correct? And either return, as a string, my special Github terms-of-use key or else the SP's entityID.

Basically.

Since you also want the relying party ID in the generic case, you would inject the Predicate and a reference to "shibboleth.RelyingPartyIdLookup.Simple" in a map object and inject the map as the customObject-ref. Then something like this works:

key = null;
if (custom["condition"].test(input)) {
    key = "tagged";
} else {
    key = custom["rpid"].apply(input) {
}
key;

The wiring is just Spring map syntax:

<util:map id="something">
    <entry key="condition" value-ref="predicateBean" />
    <entry key="rpid" value-ref="shibboleth.RelyingPartyIdLookup.Simple" />
</util:map>

By far the hard part is all the XML to define the predicate for this, but that's in the standard examples provided for testing tags.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net