Blackboard Transact & IDP 3.x
powela at rpi.edu
Wed Apr 6 19:22:45 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.
><!-- Custom Blackboard Relying Party 1 -->
><bean parent="RelyingPartyByName" c:relyingPartyIds="<Your Custom
>Blackboard EntityID 1">
><bean parent="SAML2.SSO" p:encryptAssertions="false"
>p:signResponses="false" p:signAssertions="false" />
><bean parent="SAML2.AttributeQuery" />
>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:
>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.
>James Gross | Enterprise Application and CMS Developer (Enterprise Web
I still have been unable to get transact to work with IDP 3.x. There have
been a couple of threads on the transact list from people in a similar
situation. The BB rep says they have a new document in ³QA² which will
elicit what the correct configuration is, and I see James had gotten it to
work, but I am following his and others points and it still doesn¹t work.
He did give me the idea of overrides for every entityid in their metadata,
as opposed to just the ones I see in the logs, but that didn¹t help (I
assume by ³information on 3 different Service Providers² he means the
entityids in the metadata)
1. I am aware of they use of friendly names and I am using the same
configuration from IDP v2. The OIDs they use in their "how to" document
are incorrect but they seem to ignore them and use the friendly names. I
am assuming a working configuration for what to release from v2 will work
in v3. I am also releasing a transientid like they want.
2. I have relying party overrides for all of their entityids and I appear
to have the correct configuration as I see changes in DEBUG statements if
I turn on encryption etc. The overrides I settled on are the same as James
3. I don¹t have any default attributes released except for a transientId
(via releaseTransientIdToAnyone). This worked fine in v2 so I don¹t see
why this is a problem (I did go ahead and try and not automatically
release it to their entityids and release it specifically but doesn¹t
appear to make a difference).
4. I am using a test server with a different entityid than my production
one but transact does not appear to care. I have routinely switched back
and forth between the production v2 server and a test v2 server with no
problem (as long as you tell it the correct endpoints in their
The logs suggest that the call comes in for attribute release and then a
subsequent SOAP attribute query comes in, just like I see with my
production server. I appear to be releasing the same things I do to the
SOAP call with v3 that I did with v2. The only possible difference I see
is that the assertion appears to be being encrypted with the SOAP
response. I tried SHA1 but that didn¹t appear to make a difference
More information about the users