Testing the SAML functionality with shibboleth and NGINX integration

[jkmuthusamy]

Hi, We integrated Shibboleth module in our project with nginx. We are testing the integration with below URL https://hostname:8443/Shibboleth.sso/

Could you please confirm this is the right way of testing?

I'm able to run shibd, supervisord and nginx plus instances. Now i'm trying to test the working of Shibboleth SAML integration with the application running in nginx.

When i try to hit https://hostname:8443/Shibboleth.sso/Status , i'm getting the below output

but when i hit https://hostname:8443/Shibboleth.sso/Status/ (added'/' after "Status", like /Status/), i'm getting the below output

In our application we need to interact with PingFederate(Idp) from shibboleth . Want to know do we need to generate any metadata xml from shibboleth? We have metadata xml from our idp which we gave with tag

Idp Entity Id we gave as

<SSO entityID="https://my-idp-url/shibboleth">
              SAML2
</SSO> 

Below is the shibboleth2.xml configs:

Shibboleth2.xml:

<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config" xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config" clockSkew="180">

<OutOfProcess tranLogFormat="%u|%s|%IDP|%i|%ac|%t|%attr|%n|%b|%E|%S|%SS|%L|%UA|%a" />
<RequestMapper type="XML">
<RequestMap>
    <Host name="https://d1l00313g.dc01.its.hpecorp.net"
          authType="shibboleth"
          requireSession="true"
          redirectToSSL="443">
        <Path name="/secure" />
        <Path name="/secure2/shibboleth" />

    </Host>

</RequestMap>

<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
<ApplicationDefaults entityID="https://d1l00313g.dc01.its.hpecorp.net/shibboleth"
    REMOTE_USER="eppn subject-id pairwise-id persistent-id"
    cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">

    <!--
    Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
    Each Application has an effectively unique handlerURL, which defaults to "/Shibboleth.sso"
    and should be a relative path, with the SP computing the full value based on the virtual
    host. Using handlerSSL="true" will force the protocol to be https. You should also set
    cookieProps to "https" for SSL-only sites. Note that while we default checkAddress to
    "false", this makes an assertion stolen in transit easier for attackers to misuse.
    -->
    <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
              checkAddress="false" handlerSSL="true" cookieProps="https">

        <!--
        Configures SSO for a default IdP. To properly allow for >1 IdP, remove
        entityID property and adjust discoveryURL to point to discovery service.
        You can also override entityID on /Login query string, or in RequestMap/htaccess.
        -->
        <SSO entityID="https://login-itg.ext.hpe.com/shibboleth">
          SAML2
        </SSO>

        <!-- SAML and local-only logout. -->
        <Logout>SAML2 Local</Logout>

        <!-- Administrative logout. -->
        <LogoutInitiator type="Admin" Location="/Logout/Admin" acl="127.0.0.1 ::1" />

        <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
        <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

        <!-- Status reporting service. -->
        <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>

        <!-- Session diagnostic service. -->
        <Handler type="Session" Location="/Session" showAttributeValues="false"/>

        <!-- JSON feed of discovery information. -->
        <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
    </Sessions>

    <!--
    Allows overriding of error template information/filenames. You can
    also add your own attributes with values that can be plugged into the
    templates, e.g., helpLocation below.
    -->
    <Errors supportContact="root@localhost"
        helpLocation="/about.html"
        styleSheet="/shibboleth-sp/main.css"/>

    <!-- Example of locally maintained metadata. -->

    <MetadataProvider type="XML" validate="true" path="itg_sp_nginx_metadata_uid.xml"/>

    <!-- Example of remotely supplied batch of signed metadata. -->
    <!--
    <MetadataProvider type="XML" validate="true"
                url="http://federation.org/federation-metadata.xml"
          backingFilePath="federation-metadata.xml" maxRefreshDelay="7200">
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
        <MetadataFilter type="Signature" certificate="fedsigner.pem" verifyBackup="false"/>
        <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
          attributeName="http://macedir.org/entity-category"
          attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          attributeValue="http://refeds.org/category/hide-from-discovery" />
    </MetadataProvider>
    -->

    <!-- Example of remotely supplied "on-demand" signed metadata. -->
    <!--
    <MetadataProvider type="MDQ" validate="true" cacheDirectory="mdq"
                baseUrl="http://mdq.federation.org" ignoreTransport="true">
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
        <MetadataFilter type="Signature" certificate="mdqsigner.pem" />
    </MetadataProvider>
    -->

    <!-- Map to extract attributes from SAML assertions. -->
    <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>

    <!-- Default filtering policy for recognized attributes, lets other data pass. -->
    <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

    <!-- Simple file-based resolvers for separate signing/encryption keys.
    <CredentialResolver type="File" use="signing"
        key="sp-signing-key.pem" certificate="sp-signing-cert.pem"/> -->
    <CredentialResolver type="File" key="/opt/serviceproxy/conf/ssl/svcproxy-dev.key" certificate="/opt/serviceproxy/conf/ssl/svcproxy-dev.pem"/>

</ApplicationDefaults>

<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

<!-- Low-level configuration about protocols and bindings available for use. -->
<ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>

Could any one please provide how i can test the working of shibboleth and SAML functionality ?

[davidjb]

The output you've got coming from https://hostname:8443/Shibboleth.sso/Status and https://hostname:8443/Shibboleth.sso/Status/ are right -- these are standard responses returned by shibresponder so that's set up okay. For testing authorisation, the simplest option is to set up a quick backend application like Bottle -- see https://github.com/nginx-shib/nginx-http-shibboleth/wiki/bottle -- and test attributes and an auth cycle complete correctly.

As for integrating with other software or configuration of Shibboleth, this issue tracker is just for reporting issues with the nginx integration. You can direct support requests to the Shibboleth Users mailing list (https://www.shibboleth.net/community/lists/) -- they can assist you with specific config or application issues. Otherwise, speak with your software vendor about what needs to be configured and where for SAML etc.

PR and contributions to the wiki are welcome if you can share your configuration.