Blackboard Transact & IDP 3.x

Tue Mar 29 10:54:33 EDT 2016

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.
*        *
*        <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.
*    *
*    <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)

UNC Charlotte | Information Technology Services

9201 University City Blvd. | Charlotte, NC 28223

Phone: 704-687-0298 | Office: Kennedy 301-C39

jgross15 at uncc.edu | http://www.uncc.edu
------------------------------

If you are not the intended recipient of this transmission or a person
responsible for delivering it to the intended recipient, any disclosure,
copying, distribution, or other use of any of the information in this
transmission is strictly prohibited. If you have received this transmission
in error, please notify me immediately by reply e-mail or by telephone at
704-687-0298. Thank you.

On Mon, Mar 28, 2016 at 10:03 PM, Michael A Grady <mgrady at unicon.net> wrote:

>
> > On Mar 28, 2016, at 3:49 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
> >
> >> Ok, good to know. I really don’t know how they’re differentiating
> between
> >> IdP 2 and 3, or what their actual requirements are. Based on this
> thread, I’m
> >> hoping someone else has some experience with what exactly is needed to
> >> get Bb Transact working, as they don’t seem to know much themselves.
> >
> > My point is that of the three possible issues, two of them are trivial
> for anybody to test out. The third means they have a bug and there's
> nothing you can do to fix it. Nailing down which of those is involved is
> not really something you need them to do.
> >
> > -- Scott
> >
> > --
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
> Unless Blackboard Transact has changed something since I helped an
> institution integrate with them in fall of 2014 (one would hope they have
> evolved their SAML implementation), the following were true then:
>
>  - their requirements involved having to match the actual FriendlyName to
> their needs, they did not use the real on-the-wire attribute names
>
>  - they don't take your IdP's certificate, which means they can't verify
> the signature on the response, and thus there is *no* security on the
> SAMLv2 response you send them. Which is also why (one surmises) they only
> accepted a Transient or CryptoTransient NameID.
>
>  - so even if you send a bunch of attributes on the front-channel, they
> *will* send a backchannel Attribute Query, because the TLS verification
> there is the thing that provides security around your "SAML interaction"
> with them
>
>  - the cert you present for the backchannel needs to have in it the name
> under which they are accessing the server. I don't think it needs to be a
> CA-issued cert, but I don't recall what we ended up having actually
> working. It took a number of tries, and there is no access to any logs on
> their (Blackboard's side) as to what is happening on their end.
>
> --
> Michael A. Grady
> IAM Architect, Unicon, Inc.
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160329/8a631f30/attachment.html>