Configuring attributes

[Raymond DeCampo]

Well I have made some progress.  I found the attribute-filter.xml file
and after entering in the configuration below, I am now getting the
"mail" attribute returned from the IdP to the samltest.id SP.  Thanks
to everyone who took the time to look at my questions.

I added the following to attribute-filter.xml:

        <AttributeFilterPolicy>
            <PolicyRequirementRule xsi:type="ANY" />
            <AttributeRule attributeID="mail" permitAny="true" />
        </AttributeFilterPolicy>

Thanks again, I'm sure I'll be back with more questions later.

Ray

On Sun, May 31, 2020 at 5:34 PM Raymond DeCampo <ray at decampo.org> wrote:
>
> Hello all,
>
> First let me give you an overview of what I am trying to accomplish.  I maintain an application which currently uses an SSO for authentication.  Just to be clear the SSO software etc, is run by the owner of the application, which is to say I have no control over it.  The client wants to move to SAML for authentication in place of the existing SSO scheme.
>
> I'm new to SAML so one of the goals I am trying to achieve is to gain some familiarity with the technology.  For development purposes I wanted to set up a separate SAML IdP which I would have control over.  When developing the application it is much easier to be able to log in as a number of different users so I wanted to set up something that would help us in that manner.
>
> Ultimately my hope is to have an instance of Shibboleth IdP running with a custom backend authentication which suits my development needs.  (https://wiki.shibboleth.net/confluence/display/IDP4/PasswordAuthnConfiguration#PasswordAuthnConfiguration-CustomBack-Ends)
>
> So I have started by installing Shibboleth IdP on a CentOS 7 VM using Wildfly 19.1 (servlet-only distribution) as the container.  After a couple of bumps in the road I'm pleased to say that I managed to get the server running.  Furthermore I set up an instance of HTPasswdAuthnConfiguration and I was able to login using samltest.id as the SP.
>
> So far so good.  I noticed after logging in using samltest.id that it reported the value of some attributes.  In particular I noticed that REMOTE_USER was blank.  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.
>
> I searched the SP log on samltest.id and did not find the username I used anywhere.  My takeaway was that somehow some configuration is missing that would cause the username to be returned.
>
> 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.
>
> So, my question at the moment is, how do I configure my Shibboleth IdP instance to include the REMOTE_USER information as an attribute?  Also, is there a standard way that SAML IdPs will communicate back the identity of the authenticated user if not REMOTE_USER?
>
> Thanks,
> Ray
>