Blackboard Transact and IdP 3

[James McCartin]

The SP does ignore the attributes sent in the HTTP POST and then queries the IdP.  What can I look at to confirm that my v3 IdP supports this type of attribute query?

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Tuesday, May 24, 2016 11:00 AM
To: users at shibboleth.net
Subject: Re: Blackboard Transact and IdP 3

* 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|_281E3
> 20160518T091808Z|6148A90137BEB2F951454AAFD5E|https://sp.transactsp.com
> 20160518T091808Z|/shibboleth-sp/eacct-loyola-sp.blackboard.com/eaccoun
> 20160518T091808Z|ts|urn:mace:shibboleth:2.0:profiles:saml2:sso|https:/
> 20160518T091808Z|/shibprodapp.loyola.edu/idp/shibboleth|urn:oasis:name
> 20160518T091808Z|s:tc:SAML:2.0:bindings:HTTP-POST|_37e97a02028ff0c58cc
> 20160518T091808Z|f9d21c2415708|nsbabirye|urn:oasis:names:tc:SAML:2.0:a
> 20160518T091808Z|c:classes:PasswordProtectedTransport|eduPersonPrincip
> 20160518T091808Z|alName,eduPersonAffiliation,surname,eduPersonScopedAf
> 20160518T091808Z|filiation,loyolaID,givenName,memberOf,commonName,loyC
> 20160518T091808Z|ampusHousing,BblastName,transientId,BbgivenName,eduPe
> 20160518T091808Z|rsonTargetedID,BbuserName,email,Bbemail,displayName,|
> 20160518T091808Z|_50a2bc08a2dc76a9e945e2684aa880e3||
> 
> 20160518T091809Z|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_139A6FB632
> 20160518T091809Z|4A1B8F6EB0044E5FFCD7B1|https://sp.transactsp.com/shib
> 20160518T091809Z|boleth-sp/eacct-loyola-sp.blackboard.com/eaccounts|ur
> 20160518T091809Z|n:mace:shibboleth:2.0:profiles:saml2:query:attribute|
> 20160518T091809Z|https://shibprodapp.loyola.edu/idp/shibboleth|urn:oas
> 20160518T091809Z|is:names:tc:SAML:2.0:bindings:SOAP|_ad00eddc06406f88f
> 20160518T091809Z|c4b2063ee36cae1|nsbabirye||eduPersonPrincipalName,edu
> 20160518T091809Z|PersonAffiliation,surname,eduPersonScopedAffiliation,
> 20160518T091809Z|loyolaID,givenName,memberOf,commonName,loyCampusHousi
> 20160518T091809Z|ng,BblastName,transientId,BbgivenName,eduPersonTarget
> 20160518T091809Z|edID,BbuserName,email,Bbemail,displayName,|_50a2bc08a
> 20160518T091809Z|2dc76a9e945e2684aa880e3|_21f765d7e371d879a7a341218ad1
> 20160518T091809Z|9816,|

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|_A7CED
> 20160519T094437Z|B9D1C609C863316C7A5D2E53A3B|https://sp.transactsp.com
> 20160519T094437Z|/shibboleth-sp/eacct-loyola-sp.blackboard.com/eaccoun
> 20160519T094437Z|ts|http://shibboleth.net/ns/profiles/saml2/sso/browse
> 20160519T094437Z|r|https://shibprodapp.loyola.edu/idp/shibboleth|urn:o
> 20160519T094437Z|asis:names:tc:SAML:2.0:bindings:HTTP-POST|_eb749e6e49
> 20160519T094437Z|84aaebd70b94400b5340bb|jmccartin|urn:oasis:names:tc:S
> 20160519T094437Z|AML:2.0:ac:classes:PasswordProtectedTransport|BblastN
> 20160519T094437Z|ame,commonName,telephoneNumber,Bbemail,eduPersonAffil
> 20160519T094437Z|iation,displayName,givenName,BbuserName,BbgivenName,t
> 20160519T094437Z|itle,eduPersonScopedAffiliation,loyCampusHousing,surn
> 20160519T094437Z|ame,eduPersonPrincipalName,email|AAdzZWNyZXQxGfgGRtIp
> 20160519T094437Z|zGacHGAKrI0Fwk8ZmTQgFviVuOzTpV+gGBdhSzb0i67h3BFoFaQsn
> 20160519T094437Z|6nbcDUdhqx/7QbykjV/0tqOcHp1CFdPtQ1fOKsCllNHlsliSYqhf5
> 20160519T094437Z|/k4Ulcz0r8DuWS7rBJ98SH5iZD0hbnjYHTsEWnYiO5UP3FpD/qyxt
> 20160519T094437Z|RtH+HLCOTBe2tojbzQ0I=|_5ad865cc85a89cb0953ee16b63fddf
> 20160519T094437Z|03|
> 
> 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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net