users Digest, Vol 57, Issue 193

Powell, Alan powela at
Thu Apr 7 16:36:18 EDT 2016

Argh. I finally got IDP 3.x to work with Blackboard eAccounts/transact. I
had to make an additional change to the relaying party overrides to
prevent the assertion in the AttributeQuery from being encrypted

<bean parent="RelyingPartyByName" c:relyingPartyIds=³,You custom Entity
            <property name="profileConfigurations">
                    <bean parent="SAML2.SSO" p:encryptAttributes="false"
p:encryptNameIDs="false" p:signResponses="false" p:signAssertions="false"
p:encryptAssertions="false"  />
                    <bean parent="SAML2.AttributeQuery"
p:encryptAssertions="false" />


> ----------------------------------------------------------------------
>Message: 1
>Date: Tue, 29 Mar 2016 10:54:33 -0400
>From: James Gross <JamesGross at>
>To: Shib Users <users at>
>Subject: Re: Blackboard Transact & IDP 3.x
>	<CANWvXdBtryUiarMtj=_aZOOXjtGvNYTSc17Z7jVRe473qMhzEQ at>
>Content-Type: text/plain; charset="utf-8"
>We have had Blackboard Transact functioning with the Shibboleth IdP V3 for
>a while now. Hope this helps.
>To elaborate on the response by Michael:
>*Relying Party Overrides:*
>The metadata they provided contains information on 3 different Service
>Providers. It was necessary to create relying party overrides for each of
>them. Note the need to add in the SAML2.AttributeQuery profile as well due
>to their use of the follow-up query.
>*        <!-- Custom Blackboard Relying Party 1 -->*
>*        <bean parent="RelyingPartyByName" c:relyingPartyIds="<Your Custom
>Blackboard EntityID 1">*
>*                <property name="profileConfigurations">*
>*                    <list>*
>*                        <bean parent="SAML2.SSO"
>p:encryptAssertions="false" p:encryptAttributes="false"
>p:encryptNameIDs="false" p:signResponses="false" p:signAssertions="false"
>*                        <bean parent="SAML2.AttributeQuery" />*
>*                    </list>*
>*                </property>*
>*        </bean>*
>*Custom Attributes:*
>Their system does not use standard attributes. They have custom attribute
>names that must match
>(bb_email, bb_givenName, bb_middleName, bb_lastName, bb_userName,
>bb_customerCardNumber, bb_customerNumber).
>New attribute resolver definitions were needed to provide these for
>to all three of their service providers, for example:
>*    <resolver:AttributeDefinition xsi:type="ad:Scoped"
>scope="%{idp.scope}" id="bb_email" sourceAttributeID="samaccountname">*
>*        <resolver:Dependency ref="myLDAP" />*
>*        <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString"
>name="urn:mace:dir:attribute-def:mail" />*
>*        <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString"
>name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="BbSPEmailAddress"
>*    </resolver:AttributeDefinition>*
>*Restrict Default Attribute Release:*
>It was necessary to exclude their service providers from the release of
>default attributes that have been configured to be released to any
>registered SP. Their system could not handle the extra data.
>*    <!-- Attributes released to any SP -->*
>*    <afp:AttributeFilterPolicy id="releaseToAnyone">*
>*        <afp:PolicyRequirementRule xsi:type="basic:NOT">*
>*                <basic:Rule xsi:type="basic:OR">*
>*                        <basic:Rule
>xsi:type="basic:AttributeRequesterString" value="<Your Custom Blackboard
>EntityID 1" />*
>*                        <basic:Rule
>xsi:type="basic:AttributeRequesterString" value="<Your Custom Blackboard
>EntityID 2" />*
>*                        <basic:Rule
>xsi:type="basic:AttributeRequesterString" value="<Your Custom Blackboard
>EntityID 3" />*
>*                </basic:Rule>*
>*        </afp:PolicyRequirementRule>*
>*        <afp:AttributeRule attributeID="defaultAttribute1"
>*        <afp:AttributeRule attributeID="defaultAttribute2"
>*     </afp:AttributeFilterPolicy>*
>*James Gross* | Enterprise Application and CMS Developer (Enterprise Web

More information about the users mailing list