metadata-driven attribute definition

Joshua Dachman jdachman at
Mon Jul 15 10:32:19 EDT 2019

It seems to me that I asked a "how" question and the response I'm getting
is "why do that?" I've explained the why--to have a purely metadata-driven
approach. To give some more context to that, I'm dealing with hundreds of
SP's here (and the number is constantly growing), each with different
requirements regarding the names of the attributes they expect. It seems to
me that the IDP should have a stable configuration, and anything
SP-specific should be signaled in the SP-metadata alone.

I was hoping a purely metadata-driven approach could be wired up, but the
impression I'm getting is that it will require development work. If you
have any guidance on how to do that, please let me know.

Thank you,
Joshua Dachman

On Mon, Jul 15, 2019 at 8:48 AM Peter Schober <peter.schober at>

> * Peter Schober <peter.schober at> [2019-07-15 14:31]:
> > * Joshua Dachman <jdachman at> [2019-07-14 23:00]:
> > > The idea is to be metadata-driven here. Yes, the same can currently be
> > > achieved through addition of tags in attribute-resolver.xml, but then
> every
> > > time an SP desires a custom mapping it must be added there rather than
> in
> > > the SP's metadata.
> >
> > So far I found adding another AttributeEncoder with a relyingParties
> > XML attribute to be sufficient and easy to do.
> Oh wait, you didn't ask about one-off attribute names in metadata (for
> which a differing encoder would be relevant) but you wanted to use a
> different InputAttributeDefinition for a given standard attribute
> depending on the SP entity?
> I don't think I ever had to handle that case and certainly "metadata
> ftw!" wouldn't have been my initial reaction.
> -peter
> --
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list