SP not receiving attributes from our IdP

[Gould, Samuel]

Hi Scott,

Thanks for your response.

We initially changed our hostname because many within our organization were
unhappy with the existing one.  They thought it was too vague and didn't
represent the server's purpose of facilitating SSO.  Regardless, it seems to me
that changing hostnames provides its pros and cons, and is not inherently bad.

Yes, it means that we have to contact all our SPs, and yes, it means that we
had to work around some deficiencies in the install.sh script for Shib v3 (the
implicit assumption that entityID contains the hostname -- thus generating bad
certificates and config files when the assumption is wrong), but it provides
the distinct advantage of having a more flexible transition phase.  For a
beginner such as myself, the peace of mind of not creating a "flag day" for
this (essentially) one-man team is worth the trade-offs.

That said, I am still learning and might be ignorant of some important facts.
Please fill me in if that is the case.

Like I said in my response to David, I got my terminology wrong.  The SAML
assertion _was_ bad.  I just meant to say that the authentication statement
was OK.  Sorry about that.  Also, if the SP is requesting attributes (and they
are), then it has to be SAML 2, right?

--Sam

On 9/15/16, 7:43 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

    On 9/15/16, 8:23 PM, "users on behalf of Gould, Samuel" <users-bounces at shibboleth.net on behalf of Samuel.Gould at sdstate.edu> wrote:
    
    > - My organization is simultaneously running a Shib v2 and Shib v3 IdP
    >      - We just recently spun up the Shib v3 IdP, and gave it a different hostname
    >        than the Shib v2 IdP; the entity IDs are the same
    
    I won't belabor the point, but this is the fundamental mistake, you simply don't, and don't need, to do this. The swap should be done by testing as much as feasible ahead of time, and then simply re-address in DNS and do final cleanup.
    
    > - According to the SAML Tracer FF plugin, no `<AttributeStatement>' is sent
    
    > - Verified that our IdP provides correct SAML assertions in response to this
    >        SP (determined with SAML Tracer FF plugin)
     
    Those statements are mutually exclusive.
    
    If the IdP sends no AttributeStatement, then either it's a SAML 1.1 SP or no attributes were resolved or none were released. That's it.
    
    -- Scott
    
    
    -- 
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net