Attribute Registry vs Attribute Resolver - best practice?

[Mark Cairney]

Hi all,


Having went through our config we could do some simplification but there 
are some attributes like eduPersonEntitlement and eduPersonAssurance 
where we're doing some funky things with scripted + mapped attributes 
where it's probably not feasible.

Happy to keep things as they are and move some of the simpler attribute 
definitions into the registry, just thought I should check that what I 
was doing is sane/sensible and that I'm not painting myself into a corner.

I also had some issues where some config items were missing but I was 
able to find these in the '-513' files that were generated as part of 
the upgrade process.

Kind regards,

Mark

On 11/10/2024 16:14, Cantor, Scott wrote:
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
>
>> Having gone through the procedure on our Dev IdP it seems
>> to me like using the attribute-registry.xml is the documented
>> method for handling attributes coming upstream from Azure
>> AD. [1],[2]
> I would say that for decoding, yes, the registry is the way it should be done.
>
> The support for AttributeEncoders in the resolver implements the mappings bidirectionally but it's very confusing/awkward to set that up if the goal is to decode SAML and not to also encode it. Borderline bizarre, and it makes no sense. That's why I started from scratch, and I'm quite happy with how it turned out.
>
> I think it's confusing at times primarily because of history and what people are used to, and if it had been there to begin with it would be much more obvious as a way to do things.
>
>> To do this without changing how I handle the existing
>> attributes getting  looked up from LDAP I uncommented the
>> 'shibboleth.AttributeRegistryResources' block in services.xml
>> but in attributes/default-rules.xml I've commented out
>> everything except the new azureClaims.xml file e.g.
> Right. It's your config, you should use what you need and change at your own pace, if at all.
>
> Having said that, if you're doing "standard" stuff with Shibboleth in the way we do things, you will radically simplify the resolver config by getting rid of anything like that and probably lose many type="Simple" AttributeDefinitions by taking an afternoon to clean it up and activate the default rules, and just export any simple data directly from the DataConnectors.
>
> For one-off stuff, I still use AttributeEncoders a fair amount. It's just two ways of doing it and sometimes one makes more sense. There's not any real chance of us dropping the old way.
>
> What is unfortunate is the current NameID generation service because I wouldn't have done all that if we'd had the registry at the time. I already built NameID decoders for the SP to use that leverage the registry and it was easy to build and use.
>
> If it had existed I certainly would have done the generation that way, but I'm not inclined for now to try and deprecate all that. Maybe at some point.
>
> -- Scott
>
>
-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk

*******************************/

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.