AttributeConsumingService/ServiceName

[rhoerbe]

The idea of AttributeConsumingService/RequestedAttributes is to allow for multiple aspects of an application to consume a different set of attributes (".. defines a particular service offered by the service provider in terms of the attributes the service requires or desires."). However, the current structure of the config does not allow the generation of multiple AttributeConsumingService elements. Also, each attribute need is conveyed with a human-readable name in ServiceName ( an description). However, the SP config uses conf.name at the entity level, not at the AttributeConsumingService level. Therefore it is not likely to produce a semantically correct ServiceName element in the resulting XML.

Suggested solution: add a AttributeConsumingService as an explicit key in the SP config, plus ServiceName and RequestedAttributes as sub-items. Deprecate the required_attributes key.

[rohe]

How would you deal with optional_attributes in that case ?

[rhoerbe]

please explain - what would be the problem with optional attributes?

[peppelinux]

@rhoerbe I faced this problem during the configuration of a SPID compliant SP.
Their specs mandates to have a ACS with a index of 0 and not 1, this made me face that I wouldn't rely on the default pysaml2's methods to construct my metadata, so I went deeper to build something my own, using pysaml's internals.

That's the result, I experimented to can change anything in there so I think that your question is usefull and it would find a good answer in a more wide approach, like a framework would have.

See here:
https://github.com/peppelinux/Django-Identity/blob/36cf34a3d7f1e10edf7414c350f5025a599e5b8f/djangosaml2_sp/djangosaml2_sp/djangosaml2_spid/views.py#L290

I can reopen this if you ask, nice to meet you here again

[listen3000]

I have the same problem with needed support for multiple languages in ServiceName. Building a custom Django view seems like an overkill. Shouldn't it be part of the library?

[Lapeth]

metadata.py, function do_attribute_consuming_service defines the service name as service_name = [md.ServiceName(text=text, lang=lang)]. It can probably be a list with multiple entries, one for each language, resulting in something like:

<ns0:ServiceName xml:lang="en">Some service name</ns0:ServiceName>
<ns0:ServiceName xml:lang="da">Et eller andet servicenavn</ns0:ServiceName>
...

It would be easy to check if conf.name is a list of tuples, and construct the service_name list by it, similar to how it's done in do_key_descriptor