Blackboard Transact & IDP 3.x

[Powell, Alan]

> 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:
 

>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
>Services)
 



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
elicits.

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
administrative interface).

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

Alan