Configuring attributes

[Cantor, Scott]

On 5/31/20, 5:34 PM, "users on behalf of Raymond DeCampo" <users-bounces at shibboleth.net on behalf of ray at decampo.org> wrote:

> This surprised me - in the SSO schemes I have used the REMOTE_USER header has been used to communicate the
> username of the authenticated user back to my application.  

REMOTE_USER is a construct of the web server protecting the application. It has nothing to do with any SSO scheme on the wire or how they work. SAML in turn is also too general to be reductively expressed as "just set REMOTE_USER", that's not sufficient to address the data, any more than it would be for OpenID Connect.

> My understanding is that in SAML, the IdP will send details back to the SP in the form of attributes in the response, as
> opposed to header information.  Please correct me if this is incorrect.

The primary means of passing data in SAML are the AttributeStatement and Attribute elements and the NameID element in the assertion Subject. Shibboleth favors the former but supports the latter.

> So, my question at the moment is, how do I configure my Shibboleth IdP instance to include the REMOTE_USER
> information as an attribute?

REMOTE_USER is a construct the SP has to support and choose how/what to map into and from where. That's not the IdP's decision. You don't control what's in it, unless you control both ends, or at least (as the SP) dictate what you are willing to consume from the IdP.

> Also, is there a standard way that SAML IdPs will communicate back the identity of the authenticated user if not
> REMOTE_USER?

There are many, and most of them are bad or fraught in some way.

Shibboleth SPs have various default mapping rules to consume SAML Attributes that are common to higher education, but identifiers in SAML have a long tortured history, federated usernames are a brutally hard problem, and the use of the NameID element in SAML is deliberately and aggressively discouraged for a lot of reasons.

The expository material in [1] is a decent starting point. The product of that specification is the only sound advice there is for a new deployment. The real world is much messier and more complex.

Commercially speaking, the standard practice in cloud land is to *not* federate, silo off every customer from each other so the identifiers don't actually need to be unique, and simply tell people to send anything they want in the NameID element without regard for the standard.

-- Scott

[1] https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.pdf