Does mod_shib ever do AttributeQueries?

[Wessel, Keith]

Yep, Tom, we're always releasing attributes. But if someone in an active directory OU other than the one we query for attributes manages to authenticate (via AD Kerberos), we wouldn't return any attributes. I think that explains this tiny number of logins.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
Sent: Tuesday, April 15, 2014 3:34 PM
To: Shib Users
Subject: Re: Does mod_shib ever do AttributeQueries?

On Tue, Apr 15, 2014 at 4:19 PM, Wessel, Keith <kwessel at illinois.edu> wrote:
> Thanks, Tom, that's a good start. I already checked, and should have 
> included in my earlier note: all of these on-campus SPs are doing SAML2 attribute queries, and I know they're all running SAML2-compliant SPs.

Does your IdP *always* push attributes (if in fact there are attributes to push)? If so, you can conclude these SPs are issuing a redundant attribute query.

> Is mod_shib smart enough, if it receives an assertion without any attributes, to try an attribute query?

I wouldn't call that "smart" behavior but it's perhaps the only thing the SP can do. If the SP doesn't get the attributes it wants, it can't possibly know if the IdP is acting according to policy (no attributes released, period) or if the IdP intends for the SP to query. If you take the SAML2 AttributeService endpoint out of metadata, you force the issue on the SP.

> If so, this could have been a fluke when the post content from the IDP didn't make it through to the SPs a hand full of times.

Not sure what you mean but in any case let me be explicit: 1) configure your IdP to *always* push attributes, and then 2) remove the
SAML2 AttributeService endpoint from metadata. That brings you one tiny step closer to where you want to be. The big question is: Can you get away with not supporting SAML1?

Tom
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net