Attribute filter
Rod Widdowson
rdw at steadingsoftware.com
Thu Jul 3 07:22:20 EDT 2014
> In retrospect, AttributeInMetadata is a terrible name itself, but I think
> I picked that after not being able to come up with anything good. Seems
> like RequestedAttributeInMetadata would have been better, though, maybe we
> should alias that.
That would make a lot of sense.
> And I wonder if we should alias/rename some of the older functions that
> have AttributeRequester in them if there's no longer an Issue parallel, to
> shorten the names.
As would that. They are trivial to do. The only question whether it is
worthwhile emitting a log.info when we meet the old names as an early step
towards deprecating & then remving in V4.
> Using it for EntityAttribute policy is definitely a secondary case that's
> usually going to be more trouble than it's worth.
Yes. Very much advanced use and it just doesn't fit with the uses I've seen
for EntityAttributes in metadata.
> How about using "AttributeRequesterMappedEntityAttributeMatch" or maybe
> just "MappedEntityAttributeMatch" for the new one?
I don't like that too much since it although it describes what the code is
doing, it doesn't describe what the deployer will see. They don't need to
know what the SAML attributes have been reversed matched, just that their
IdP will only release the attributes that the SP has designated. As a
_class_ name I like it, since it does describe exactly that, down to the
fact that it is neutral as to where the attributes were mapped from. I
think that "RequestedAttributeInMetadata" pretty much sums it up for me. We
can then leave EntityAttributeInMetadata in place and leave it undocumented,
or just remove it.
> (That leads to an interesting question...how would we support inexact
> matching rules for mapped values, since the syntax for that would have to
> be extensible? I suspect the answer is we leave that to scripting for
now.)
I’d agree: "inexact" feels like an imprecise statement and we really don't
want to get into a language to define it. Or is inexactness defined
somewhere that I missed?
/R
More information about the dev
mailing list