Add custom attributes to assertion

[Cantor, Scott]

> > The requirement now is to encode some of these attributes in a rather
> > specific manner, which seems to comply with SAML2-Core, e.g.:

Comply with and "something you should consider doing" are somewhat distinct. You really should not need to do this, but also, no, that's *not* valid. It's acceptable to embed XML Attributes in an AttributeValue element, but you cannot embed actual values of an attribute in the Attribute element. That extensibility is there for a different purpose entirely.

> > So, basically I can either use a custom Attribute Encoder (is that
> > even possible without lots of customization and what would be a good
> > starting point?)

The existing code is the only starting point, and then you're left with the problem that you'd also have to learn enough Spring and do custom XML schema work to set up the configuration support in your own namespace. Alternatively you could punt and wire up AttributeDefinition and the associated AttributeEncoder objects in native Spring XML and load that into the resolver.
 
> > or do it in some form of post-authn interceptor, that
> > adds my attributes independently of the attribute-resolver.

This isn't about the resolver. The resolver is where encoders are configured for various reasons but it's not where they're used. You could do something really ugly in an outbound interceptor *if* you don't need the assertions to be signed, but there's no point, it's more work doing that than doing an encoder.

> > Any better options and what way would you recommend? Are there
> > existing solutions for that?

I would recommend you not do this and that applies to the "put XML Attributes inside an AttributeValue element" idea. What you propose is entirely out of bounds for SAML.

> My idea is to basically store the attribute values ("somevalue" in the
> example above) as IdPAttributes while processing and then deal with them
> in the Attribute Encoder.

That's not possible. You would have to store all of the data you need to encode within a given IdPAttributeValue subclass, just as the Scoped case stores both the value and scope within a value type so the encoder has the access it needs.

> - Does this make sense at all or should I approach this differently?

What you specifically proposed is absolutely unacceptable, and in fact isn't even schema legal, since Attribute requires at least one AttributeValue element.

-- Scott