Add custom attributes to assertion

[David Huebner]

Hi Scott,

thanks for your answer.

I absolutely agree that this is not how things should be done, but in 
this specific case that's our requirement and up until this point I 
expected this to be a valid (albeit unusual) scenario in SAML2.

Let me explain my thoughts.

Quoting from SAML2-Core [1], page 30:

"Arbitrary attributes: This complex type uses an extension point to 
allow arbitrary XML attributes to be added to constructs without the 
need for an explicit schema extension. [...]"

I understand "arbitrary" as in there are no hard restrictions on what I 
can use these attributes for.

"<element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>"

So it's zero or more.

"The meaning of an <Attribute> element that contains no <AttributeValue> 
elements depends on its context. Within an <AttributeStatement>, if the 
SAML attribute exists but has no values, then the <AttributeValue> 
element MUST be omitted."

Which does say nothing about the opposite (i.e. an attribute has values) 
case.

Maybe I'm missing something.


Cheers.

[1]: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

On 10.10.2017 18:32, Cantor, Scott wrote:
>>> 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
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2269 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20171011/47dcbfeb/attachment.p7s>