This information was last reviewed in November, 2018, by Scott Cantor

Change Log:

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

This is a page for documenting Shibboleth integration with ProofPoint

I did not have access to any particular documentation from the vendor, but I believe I exchanged some email with their support staff to verify some of the limitations.

Identity Provider Metadata

The application has a web interface that provides individual fields to configure the IdP information, in fairly self-evident fields. Note that that the logout URL it wants is an actual SAML logout endpoint at the IdP, not the proprietary redirect version. It accepts two signing certificates so hopefully that helps with key rollover, though this wasn't tested.

Service Provider Metadata

The dialog box for IdP details is interspersed with fields about the SP's own entityID and URLs, but it will also generate metadata on the Advanced tab, which I hand-edited afterwards to load into the IdP. Noteworthy: it doesn't support XML Encryption but does sign its requests and so includes a key for that in the metadata.

Profile Requirements

Encryption isn't supported so has to be disabled (or the idp.encryption.optional property tutrned on). There weren't any other special requirements.

SAML Logout does appear to work.

Example Shibboleth Configuration

Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.

Excerpt from relying-party.xml

<!-- Container for any overrides you want to add. -->
 
<util:list id="shibboleth.RelyingPartyOverrides">
 
    <!-- other overrides... -->
 
    <bean p:id="example.DisableEncryption" parent="RelyingPartyByName">
        <constructor-arg name="relyingPartyIds">
            <list>
                <value>your ProofPoint entityID</value>
            </list>
        </constructor-arg>
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                <bean parent="SAML2.Logout" />
            </list>
        </property>
    </bean>
 
</util:list>

Required Profile Configurations

SAML2.SSO

SAML2.Logout (if desired)

Excerpt from attribute-filter.xml

<AttributeFilterPolicy id="ProofPoint">
          <PolicyRequirementRule xsi:type="Requester" value="https://saml-entity-id.proofpoint.com/<organization>_hosted" />
          <AttributeRule attributeID="eduPersonPrincipalName">
               <PermitValueRule xsi:type="ANY" />
          </AttributeRule>
</AttributeFilterPolicy>

Excerpt from saml-nameid.xml

		<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
			p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
			p:attributeSourceIds="#{ {'eduPersonPrincipalName'} }" >
			<property name="activationCondition" >
				 <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://saml-entity-id.proofpoint.com/<organization>_hosted" />
			</property>
		</bean>

Account Provisioning

The accounts have to be in place with an appropriate email address as the user ID.

NameID Requirements

It requires use of the NameID. I doubt it checks the Format, but I used the standard urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress Format to carry the data and triggered that via an <md:NameIDFormat> element in the SP's metadata.

Attribute Requirements

It does not support SAML ATtributes.

Other Considerations

There's a Test feature on the Advanced tab of the SAML dialog.

Enabling SAML apparently blocks normal password-based login, so subsequent maintenance has to be carefully coordinated in case something breaks.