Blackboard Transact and IdP 3

[Peter Schober]

* James McCartin <jmccartin at loyola.edu> [2016-05-24 16:37]:
> On my IdP v2 server, the log shows the following when logging in to Bb Transact:
> 
> 20160518T091808Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_281E36148A90137BEB2F951454AAFD5E|https://sp.transactsp.com/shibboleth-sp/eacct-loyola-sp.blackboard.com/eaccounts|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://shibprodapp.loyola.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_37e97a02028ff0c58ccf9d21c2415708|nsbabirye|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|eduPersonPrincipalName,eduPersonAffiliation,surname,eduPersonScopedAffiliation,loyolaID,givenName,memberOf,commonName,loyCampusHousing,BblastName,transientId,BbgivenName,eduPersonTargetedID,BbuserName,email,Bbemail,displayName,|_50a2bc08a2dc76a9e945e2684aa880e3||
> 
> 20160518T091809Z|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_139A6FB6324A1B8F6EB0044E5FFCD7B1|https://sp.transactsp.com/shibboleth-sp/eacct-loyola-sp.blackboard.com/eaccounts|urn:mace:shibboleth:2.0:profiles:saml2:query:attribute|https://shibprodapp.loyola.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_ad00eddc06406f88fc4b2063ee36cae1|nsbabirye||eduPersonPrincipalName,eduPersonAffiliation,surname,eduPersonScopedAffiliation,loyolaID,givenName,memberOf,commonName,loyCampusHousing,BblastName,transientId,BbgivenName,eduPersonTargetedID,BbuserName,email,Bbemail,displayName,|_50a2bc08a2dc76a9e945e2684aa880e3|_21f765d7e371d879a7a341218ad19816,|

You'll note that you're sending all that data in the HTTP POST, and
then *again* when queried by the SP. IMO the SP has an issue here:
Creating an attribute query when you've just been handed all the
attributes doesn't make any sense.

> On my IdP v3 server, the log shows the following when logging in to Bb Transact:
> 
> 20160519T094437Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_A7CEDB9D1C609C863316C7A5D2E53A3B|https://sp.transactsp.com/shibboleth-sp/eacct-loyola-sp.blackboard.com/eaccounts|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://shibprodapp.loyola.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_eb749e6e4984aaebd70b94400b5340bb|jmccartin|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|BblastName,commonName,telephoneNumber,Bbemail,eduPersonAffiliation,displayName,givenName,BbuserName,BbgivenName,title,eduPersonScopedAffiliation,loyCampusHousing,surname,eduPersonPrincipalName,email|AAdzZWNyZXQxGfgGRtIpzGacHGAKrI0Fwk8ZmTQgFviVuOzTpV+gGBdhSzb0i67h3BFoFaQsn6nbcDUdhqx/7QbykjV/0tqOcHp1CFdPtQ1fOKsCllNHlsliSYqhf5/k4Ulcz0r8DuWS7rBJ98SH5iZD0hbnjYHTsEWnYiO5UP3FpD/qyxtRtH+HLCOTBe2tojbzQ0I=|_5ad865cc85a89cb0953ee16b63fddf03|
> 
> The SOAP call is not there.  What would prevent the soap call from being made?

Sanity, usually. As per above, querying makes no sense when you
already recieved the data. (And I'm pretty sure you're sending way to
much data, but that's not your issue and none of my business, of
course.)

> <bean parent="SAML2.SSO" p:signResponses="never"
> p:encryptAssertions="false"
> p:postAuthenticationFlows="attribute-release" />
> 
> <bean parent="SAML2.AttributeQuery" p:encryptAssertions="false" />

Is turning off encryption certain to be needed with this SP?
I'd be very sceptical about also turning off signing, as this allows
for anyone to trivially impose your IDP and therefor all your subjects
to the SP. (Assuming the SP actually verifies the signatures and
denies access if it's not done with a key your IDP publishes for that
purpose.)

I can't tell you what this SP specifically requires, but the literal
answer you're seeking (how to enable queries to that SP) is the wrong
question, IMO. The SP should never create those queries in the first
place.
If, OTOH, it has been established that the SP is broken in exactly
this way (no support for attributes sent with the authentication
assertion during HTTP POST), then you'd look at analyzing your
attribute query support.
-peter