Blackboard Transact & IDP 3.x

Fri Apr 8 09:28:27 EDT 2016

Alan,
Did you include the AttributeQuery/SOAP profile in the relying party
overrides as well? That was the sticking point for me that took a while to
figure out.

*<!-- 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>*

------------------------------
*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 Wed, Apr 6, 2016 at 7:22 PM, Powell, Alan <powela at rpi.edu> wrote:

> > 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
>
>
>
>
> --
> 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/20160408/e5f8327e/attachment.html>