OpenSAML user discussion

[Brent Putman <>]

In looking at the metadata, I see that you have registered in both
TestShib 1 and TestShib 2, in one of them both by FQDN and IP address. 
I'd suggest getting rid of all but one of those, just to avoid
confusion.  I think you can delete your own entries via the "Edit"
operation.  If not, maybe Nate can assist in that.  Looks like from the
test below you were using the IP-address-named one in the TestShib 1
metadata.


Pantvaidya, Vishwajit wrote:
> Thanks. Based on this, I tried the following browser requests:
>
> https://idp.testshib.org/idp/profile/Shibboleth/SSO?providerId=https%3A%2F%2Fvishsjlaptop.selectica.com%2Fshibboleth%2Ftestshib%2Fsp&shire=http%3A%2F%2Fvishsjlaptop.selectica.com&target=login.jsp
> (i.e. providerId=https://vishsjlaptop.selectica.com/shibboleth/testshib/sp, 
> shire=http://vishsjlaptop.selectica.com/, target=login.jsp)
>   

Yeah, your shire parameter there isn't correct, or at least doesn't jibe
with metadata.  That should:
1) be the endpoint to which the POST profile will post the SAML
response.  Don't know what that is in your app.  Maybe
http://vishsjlaptop.selectica.com/ is correct, but that looks a little
suspect.  Probably should be a explicit path there.
2) it needs to match one of the AssertionConsumerService endpoints for
the Browser POST binding in your metadata entry.  Find the effective
metadata entry that you are using (easier if you get rid of all but one
of them) and in your EntityDescriptor/AssertionConsumerService entries'
Location attribute, make sure they match your SP implementation's
endpoint.  The default values that are generated are for a Shibboleth
SP, certainly not the same as your SP.  Here's what one of your entries
has, for example


            <md:AssertionConsumerService
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
               
Location="https://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST";
index="6"/>
            <md:AssertionConsumerService
                Binding="urn:oasis:names:tc:SAML:1.1:profiles:browser-post"
               
Location="http://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST";
index="7"/>



What you supply in metadata must match what you specify in the shire
parameter, and must of course match where your SP actually accepts the
posted response.

Shibboleth as you may have noticed is based heavily on the use of SAML
metadata.




> 21:51:54.365 DEBUG 
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:78]
>  - Selecting endpoint from metadata corresponding to provided ACS URL: 
> http://64.161.158.31
> 21:51:54.365 DEBUG 
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:82]
>  - Relying party role contains 4 endpoints
> 21:51:54.366 DEBUG 
> [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:101]
>  - No endpoint meets selection criteria for SAML entity 
> https://64.161.158.31/shibboleth/testshib/sp
>   

Yeah, see you have 4 ACS endpoints in the entry, but none of them are
"http://vishsjlaptop.selectica.com/";, so it can't validate that that is
a valid ACS endpoint for the entity ID that you are claiming to be.




> 21:51:54.367 ERROR 
> [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:396]
>  - No return endpoint available for relying party 
> https://64.161.158.31/shibboleth/testshib/sp
> 21:51:54.368 ERROR 
> [edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet:85]
>  - Error processing profile request
> edu.internet2.middleware.shibboleth.common.profile.ProfileException: No 
> peer endpoint available to which to send SAML response
>
> Does this mean it tried to send a saml request to my SP? Or is their 
> something missing in my configuration?
>   

It's trying to process the request, but it can't complete successfully
because of the endpoint mismatch.  But I think you're getting close.  :-)



>
>
>   
>> -----Original Message-----
>> From: Brent Putman 
>> [mailto:]
>>
>> Pantvaidya, Vishwajit wrote:
>>     
>>> By profiles, do you mean profiles as in "browser post profile" or
>>>       
>> something else?
>>     
>> No, not exactly.  In SAML 1.1. Browser POST profile only covers the POST
>> to the SP.  There was no request defined into the IdP.  IdP initiated
>> was assumed.  Shibboleth 1.x extended this profile with a simple
>> SP-initiated protocol, comprised of a GET with query parameters. The
>> protocol/profile you want is defined in:
>>
>> http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-
>> protocols-200509.pdf
>>