Attribute Registry vs Attribute Resolver - best practice?

[Cantor, Scott]

> 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