users Digest, Vol 57, Issue 193
Powell, Alan
powela at rpi.edu
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
ID>">
<property name="profileConfigurations">
<list>
<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" />
</list>
</property>
</bean>
> ----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 29 Mar 2016 10:54:33 -0400
>From: James Gross <JamesGross at uncc.edu>
>To: Shib Users <users at shibboleth.net>
>Subject: Re: Blackboard Transact & IDP 3.x
>Message-ID:
> <CANWvXdBtryUiarMtj=_aZOOXjtGvNYTSc17Z7jVRe473qMhzEQ at mail.gmail.com>
>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
>release
>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"
>permitAny="true"/>*
>* <afp:AttributeRule attributeID="defaultAttribute2"
>permitAny="true"/>*
>* </afp:AttributeFilterPolicy>*
>
>------------------------------
>*James Gross* | Enterprise Application and CMS Developer (Enterprise Web
>Services)
>
More information about the users
mailing list