How to refuse SP session when no attributes received?
Gernot Hassenpflug
gernot.hassenpflug at asahinet.com
Mon Mar 11 01:32:53 EDT 2013
Dear all,
Our SP (Shibboleth 2.4.3 with Apache 1.3, plus nginx as a front-end
web server) has gone into production with the customer (a major
university in Japan) as of this morning, and we notice that there is
one problem which I would like to understand and solve.
We set the REMOTE_USER in the <ApplicationDefaults> to the eppn.
It seems some users are being authenticated, but no attributes are
sent to the SP (whether this is caused by the customer's IdP and/or
Siteminder settings we do not yet know, but password authentication is
clearly processed successfully). In that case, REMOTE_USER is empty,
but the SP nevertheless creates a session and redirects to the
application page requested (in this case, a local application login
page is displayed).
Looking at the SSO debug output in shibd.log, we can see that for a
user who successfully accesses our SP application pages on login,
there is an <saml2:AttributeStatement></saml2:AttributeStatement>
block in the <saml2:Assertion></saml2:Assertion> block that the SP
receives from the IdP when it wants attributes (after the IdP has
successfully authenticated the user).
The only attribute we obtain is the ePPN. After this assertion
containing the desired attribute, session is created, and redirect
occurs.
For a user who ends up with the SP application login screen rather
than accessing the SP application pages, the only difference in the
final assertion is the missing attribute statement block. After that,
the SP attempts to connect to the IdP and do another attribute
query---it fails with a connect timeout.
However, the SP neverthess creates a session and redirects to the SP
application pages.
What I would like to know is if, and if so, how, one could configure
the SP to not create a session or not redirect, or otherwise declare
an error if no attributes (or not the desired attributes) are passed
from the IdP. I understand that we cannot go back to the IdP login
page since the credentials were already validated by the IdP.
As a workaround we declare "Access forbidden" if REMOTE_USER is empty
for shibboleth-protected pages.
Below is a redacted comparison of successful (attributes passed) and failed (no attributes passed) log:
SUCCESS:
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: decrypted Assertion:
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_******" IssueInstant="2013-03-11T02:12:47.707Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.ritsumei.ac.jp/idp/shibboleth</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_******">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>******=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>*****==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MII****=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://idp.ritsumei.ac.jp/idp/shibboleth" SPNameQualifier="https://ct.ritsumei.ac.jp/shibboleth">_********</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="*.*.*.*" InResponseTo="_********" NotOnOrAfter="2013-03-11T02:17:47.707Z" Recipient="https://ct.ritsumei.ac.jp/Shibboleth.sso/SAML2/POST"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-03-11T02:12:47.707Z" NotOnOrAfter="2013-03-11T02:17:47.707Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://ct.ritsumei.ac.jp/shibboleth</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2013-03-11T02:12:47.419Z" SessionIndex="****">
<saml2:SubjectLocality Address="*.*.*.*"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">WORKINGUSERID at ritsumei.ac.jp</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: extracting issuer from SAML 2.0 assertion
2013-03-11 11:12:47 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [31]: evaluating message flow policy (replay checking on, expiration 60)
2013-03-11 11:12:47 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [31]: validating signature profile
2013-03-11 11:12:47 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [31]: signature verified against message issuer
2013-03-11 11:12:47 DEBUG OpenSAML.SecurityPolicyRule.BearerConfirmation [31]: assertion satisfied bearer confirmation requirements
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: SSO profile processing completed successfully
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: extracting pushed attributes...
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: resolving attributes...
2013-03-11 11:12:47 INFO Shibboleth.SessionCache [31]: new session created: ID (_********) IdP (https://idp.ritsumei.ac.jp/idp/shibboleth) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (*.*.*.*)
2013-03-11 11:12:47 DEBUG Shibboleth.SSO.SAML2 [31]: ACS returning via redirect to: https://ct.ritsumei.ac.jp/ct/
FAIL:
2013-03-11 11:13:03 DEBUG Shibboleth.SSO.SAML2 [28]: decrypted Assertion:
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_********" IssueInstant="2013-03-11T02:13:03.011Z" Version="2.0">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.ritsumei.ac.jp/idp/shibboleth</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_******">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>********=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>********==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MII********=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://idp.ritsumei.ac.jp/idp/shibboleth" SPNameQualifier="https://ct.ritsumei.ac.jp/shibboleth">_********</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="*.*.*.*" InResponseTo="_********" NotOnOrAfter="2013-03-11T02:18:03.011Z" Recipient="https://ct.ritsumei.ac.jp/Shibboleth.sso/SAML2/POST"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-03-11T02:13:03.011Z" NotOnOrAfter="2013-03-11T02:18:03.011Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://ct.ritsumei.ac.jp/shibboleth</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2013-03-11T02:13:02.819Z" SessionIndex="********">
<saml2:SubjectLocality Address="*.*.*.*"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
2013-03-11 11:13:03 DEBUG Shibboleth.SSO.SAML2 [28]: extracting issuer from SAML 2.0 assertion
2013-03-11 11:13:03 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [28]: evaluating message flow policy (replay checking on, expiration 60)
2013-03-11 11:13:03 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [28]: validating signature profile
2013-03-11 11:13:03 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [28]: signature verified against message issuer
2013-03-11 11:13:03 DEBUG OpenSAML.SecurityPolicyRule.BearerConfirmation [28]: assertion satisfied bearer confirmation requirements
2013-03-11 11:13:03 DEBUG Shibboleth.SSO.SAML2 [28]: SSO profile processing completed successfully
2013-03-11 11:13:03 DEBUG Shibboleth.SSO.SAML2 [28]: extracting pushed attributes...
2013-03-11 11:13:03 DEBUG Shibboleth.SSO.SAML2 [28]: resolving attributes...
2013-03-11 11:13:11 DEBUG Shibboleth.Listener [29]: dispatching message (find::StorageService::SessionCache)
2013-03-11 11:13:11 DEBUG Shibboleth.Listener [9]: dispatching message (find::StorageService::SessionCache)
2013-03-11 11:13:12 DEBUG Shibboleth.Listener [8]: dispatching message (find::StorageService::SessionCache)
2013-03-11 11:13:13 ERROR Shibboleth.AttributeResolver.Query [28]: exception during SAML query to https://idp.ritsumei.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery: CURLSOAPTransport
failed while contacting SOAP endpoint (https://idp.ritsumei.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery): connect() timed out!
2013-03-11 11:13:13 ERROR Shibboleth.AttributeResolver.Query [28]: unable to obtain a SAML response from attribute authority
2013-03-11 11:13:13 INFO Shibboleth.SessionCache [28]: new session created: ID (_********) IdP (https://idp.ritsumei.ac.jp/idp/shibboleth) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (*.*.*.*)
2013-03-11 11:13:13 DEBUG Shibboleth.SSO.SAML2 [28]: ACS returning via redirect to: https://ct.ritsumei.ac.jp/ct/
Regards,
Gernot Hassenpflug
PS.
Note to Scott: I will still respond regarding passing the (web) client
IP through front-end web server to apache and to the SP, which was a
different thread. Just to let you know that is not forgotten, just the
implementation was on hold till this week.
--
Gernot Hassenpflug
More information about the users
mailing list