UnsolicitedSSO config shib 3.3.1

Jason Castor jcastor at uvic.ca
Wed Sep 27 09:19:59 EDT 2017


Hi,

I am having problems setting up an IDP initiated connection with a vendor (VendorX), using Shibboleth 3.3.1.  I have had some trouble getting properly formed metadata from the vendor, but I think what I have now should work, but I am getting the following log messages when using the Unsolicited SSO URL (eg: https://ouridp/idp/profile/SAML2/Unsolicited/SSO?providerId=VendorX):

2017-09-26 09:46:57,196 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler:  No metadata returned for VendorX in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol
2017-09-26 09:46:57,291 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID VendorX)
2017-09-26 09:46:57,328 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration

I didn't think I needed to setup UnverifiedRelyingParty, due to my config in relying-party.xml.  Turning on DEBUG for idp.loglevel.opensaml, shows that the metadata provider is being resolved

2017-09-27 05:36:35,238 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:283] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Be
ginning refresh of metadata from 'vendor-metadata.xml'
2017-09-27 05:36:35,238 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:290] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Pr
ocessing new metadata from 'vendor-metadata.xml'
2017-09-27 05:36:35,239 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:380] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Un
marshalling metadata from 'vendor-metadata.xml'
2017-09-27 05:36:35,241 - WARN [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:402] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Ent
ire metadata document from 'vendor-metadata.xml' was expired at time of loading, existing metadata retained
2017-09-27 05:36:35,242 - INFO [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:306] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Nex
t refresh cycle for metadata provider 'vendor-metadata.xml' will occur on '2017-09-27T12:41:35.242Z' ('2017-09-27T05:41:35.242-07:00' local t
ime)

When I hit the Unsolicited SSO URL I see that it does not find the entityID of 'VendorX' within my metadata provider even though that is what it is in my metadata.

2017-09-27 05:40:33,818 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:434] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Metadata backing store does not contain any EntityDescriptors with the ID: VendorX
2017-09-27 05:40:33,818 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractBatchMetadataResolver:161] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Resolved 0 candidates via EntityIdCriterion: EntityIdCriterion [id=VendorX]
2017-09-27 05:40:33,821 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:586] - Metadata Resolver FilesystemMetadataResolver VENDOR-MD: Candidates iteration was empty, nothing to filter via predicates

The config I thought is relevant is included below, did I miss something obvious?  I've been searching through the mailing list and thought I did everything required from https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration.

vendor-metadata.xml:

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
                     validUntil="2017-09-24T18:39:11Z"
                     cacheDuration="PT604800S"
                     entityID="VendorX">
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                                     Location="https://vendor.example.com/mvc/sso/saml/login"
                                     index="1" />
    </md:SPSSODescriptor>
</md:EntityDescriptor>

relying-party.xml

        <bean parent="RelyingPartyByName" c:relyingPartyIds="VendorX">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                </list>
            </property>
        </bean>


metadata-providers.xml

    <MetadataProvider id="VENDOR-MD" xsi:type="FilesystemMetadataProvider"
                              xmlns="urn:mace:shibboleth:2.0:metadata"
                              metadataFile="vendor-metadata.xml" />


Attribute-filter.xml

    <AttributeFilterPolicy id="releaseToVendorX">
            <PolicyRequirementRule xsi:type="Requester" value="VendorX"/>

            <AttributeRule attributeID="uid">
                    <PermitValueRule xsi:type="ANY"/>
            </AttributeRule>

    </AttributeFilterPolicy>

Saml-nameid.xml
(Trying to provide a standard format rather than urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                p:omitQualifiers="true"
                p:format="urn:oid:0.9.2342.19200300.100.1.1"
                p:attributeSourceIds="#{ {'uid'} }">
                <property name="activationCondition">
                        <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="VendorX" />
               </property>
        </bean>

Any pointers appreciated.

Thanks,

Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170927/1087ef17/attachment-0001.html>


More information about the users mailing list