Currently, I’m grappling with a decision regarding the handling of custom attributes in the context of SAML federation. I’m unsure whether to mandate clients to define custom attributes or if I should conform to the attributes they send. Ideally, I’d like to adopt a practice similar to some Identity Providers (IdPs), where clients can provide basic attributes like email, id, surname, etc., but I also want to enforce a unique attribute, like an SSOID, in addition to the typical NameID. Should I insist that clients define this unique attribute, or is it more common to adapt to the attributes they provide? I’m seeking insights into best practices and considerations for this aspect of SAML federation implementation.
I’m not sure I completely understand what you are looking to accomplish here. Generally speaking, if a SP wants or needs the IDP to send certain attributes over in the assertion they operate with the expectation that the IDP will do so (using the attribute names and formats that are expected) and then the SP will process that information and either complete the federation or fail it due to missing or invalid data.
If the IDP wants to send over additional attributes in the assertion they certainly can do so, however the IDP doesn’t have any way of enforcing that the SP does anything with that data.
In your scenario with the SSOID attribute, what would you be expecting the SP to do with that data?
Hi @mwtech,
Thank a lot for your response.
I find myself in a somewhat unique situation with the client. I’m currently setting up federation between two IDPs, and I’m requesting the addition of an attribute to the mapping, such as in the case of Salesforce using an SSOID representing a federation ID. However, I cannot mandate the client or the IDP to provision this attribute.
In my ideal scenario, I envision having a NameId mapped to an emailAddress, along with attributes like name, surname, and email, potentially incorporating an SSOID that could be unique between the two parties. The advantage of this approach, especially with the SSOID, is that even if the email changes over time (for example, due to a name change after marriage or divorce), the SSOID remains constant, preventing the creation of a new identity.
My question revolves around the lack of clear requirements between the two parties. The IDP has the freedom to send attributes of their choosing, and there are no explicit guidelines for attribute exchange, except for the NameId. In this context, I would like to understand the general practice. How do we typically approach situations where requirements for attribute exchange are not clearly defined, apart from the NameId?
Thank you for taking the time to read my message, and I would appreciate any insights you can provide.
Best regards.
1 Like
In scenarios like this as the IDP you are somewhat beholden to what the SP wants. If the SP requires a piece of data and the IDP does not provide it, the SP has the power to not accept the assertion due to a lack of required data. Similarly, the SP can choose to disregard any attributes the IDP sends in their assertion, such as an SSOID.
It sounds like what you really want here is the use of a pseudo-random persistent nameid, one that won’t change when something like a name changes. Of course as pointed out above this really only works if your SP supports that.
At the end of the day, in my experience you really just end up having to work with what you can work with. If you are dealing with an IDP or SP that you have no control over and no working relationship with, you really just need to roll with it. Nobody ever said SAML was pretty.
1 Like