How to add custom "RequestedAttributes" into SP metadata

[PardeepOne]

Hi,

I would like to be able to customize the way through which the SP's EntityDescriptor metadata is generated to have something similiar to this one (maybe this feature is already implemented in the library, but I haven't been able to find it :D):

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://spid.serviceprovider.it"
    ID="_0j40cj0848d8e3jncjdjss...">
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        [...]
    </ds:Signature>
    <md:SPSSODescriptor
        protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
        AuthnRequestsSigned="true"
        WantAssertionsSigned="true">
        <md:KeyDescriptor use="signing">
            [...]
        </md:KeyDescriptor>
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://spid.serviceprovider.it/slo-location"
            ResponseLocation="https://spid.serviceprovider.it/slo-location"/>
        <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
        <md:AssertionConsumerService
            index="0" isDefault="true"
            Location="https://spid.serviceprovider.it/sso-location"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:AssertionConsumerService
            index="1"
            Location="https://spidSP.serviceProvider.it/sso-location"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:AttributeConsumingService index="0">
            <md:ServiceName xml:lang="it">Set 0</md:ServiceName>
            <md:RequestedAttribute Name="name"/>
            <md:RequestedAttribute Name="familyName"/>
            <md:RequestedAttribute Name="fiscalNumber"/>
            <md:RequestedAttribute Name="email"/>
        </md:AttributeConsumingService>
            <md:AttributeConsumingService index="1">
            <md:ServiceName xml:lang="it">Set 1</md:ServiceName>
            <md:RequestedAttribute Name="spidCode"/>
            <md:RequestedAttribute Name="fiscalNumber"/>
        </md:AttributeConsumingService>
    </md:SPSSODescriptor>
    <md:Organization>
        <OrganizationName xml:lang="it">Service provider</OrganizationName>
        <OrganizationDisplayName xml:lang="it">Nome service provider</OrganizationDisplayName>
        <OrganizationURL xml:lang="it">http://spid.serviceprovider.it</OrganizationURL>
    </md:Organization>
</md:EntityDescriptor>

Thanks in advance.

[pitbulk]

The Metadata class accepts a attributeConsumingService object.

You may initialize it with a name and a description, and then use the addRequestedAttribute method to add it. This methos expects a RequestedAttribute object.

[mauromol]

Hi @pitbulk,
I need to implement SPID authentication in my company. SPID (https://www.spid.gov.it/) is the Italian government official federated authentication system for citizens and companies and is based on SAML 2.0.
After studying the topic, I selected java-saml as the library to use, because it goes straight to the point, has an excellent "quick start" guide here on GitHub and provides almost all the features I need.
However, to properly support SPID I would still need to enhance it a bit. I would like to know whether you're open to pull requests for such enhancements.
The first one (and it's the reason I'm writing here) is the ability to support multiple attribute consuming services. My plan is the following:

• allow to configure (zero or more) attribute consuming services in settings, just like the assertion consumer service: I don't see good reasons for not having attribute consuming services configured there just like the other aspects of SP configuration
• add the ability to specify the index for each attribute consuming service and its isDefault attribute
• deprecate com.onelogin.saml2.settings.Metadata.Metadata(Saml2Settings, Calendar, Integer, AttributeConsumingService) but maintain it for backward compatibility; when using this constructor, the specified AttributeConsumingService will override any other attribute consuming service specified in the Saml2Settings instance; this should guarantee the exact same behaviour if existing client code is left untouched
• add a com.onelogin.saml2.Auth.login() overloading that allows to specify the AttributeConsumingService index to send to the IdP, with a selector mechanism; all the other existing login() overloading will default to a "default selector" (i.e.: no AttributeConsumingServiceIndex specified, rely on the default one); this should guarantee backward compatibility

As an alternative to the last point, since the number of overloadings is quite huge already, I think it should be better to provide a login() overloading that takes the following signature:

public String login(String returnTo, AuthnRequest authRequest, Boolean stay, Map<String, String> parameters)

In this way, by enhancing AuthnRequest, we can specify further information required to create the actual AuthnRequest message without producing so many login() overloadings. For instance, another (lower priority) enhancement that I have in mind is the ability to specify multiple assertion consumer services, which would require another (optional, of course) selector parameter to be specified when creating the AuthnRequest.

My plan is to implement this over the current version of java-saml, so only for Java 8+. What do you think?