entityID questions

[Lohr, Donald]

1) The vendor reported back that they do not believe that our entityID 
that's a urn value is the issue.

2) In our production Shibboleth metadata are four SingleSignOnService 
Binding elements:

<SingleSignOnService 
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" 
Location="https://itfederation.jmu.edu/shibboleth-idp/SSO"/>

<SingleSignOnService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://itfederation.jmu.edu/idp/profile/SAML2/POST/SSO"/>

<SingleSignOnService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" 
Location="https://itfederation.jmu.edu/idp/profile/SAML2/POST-SimpleSign/SSO"/>

<SingleSignOnService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
Location="https://itfederation.jmu.edu/idp/profile/SAML2/Redirect/SSO"/>

The vendor is asking why does our production Shibboleth IdP metadata 
have the following Binding:

<SingleSignOnService 
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" 
Location="https://itfederation.jmu.edu/shibboleth-idp/SSO"/>

Putting that Location url in a browser goes to an error:

*HTTP ERROR: 404**
***
Problem accessing /shibboleth-idp/SSO. Reason:

Not Found


Putting the other three Location urls in a browser returns the following 
error:

*Web Login Service - Stale Request*



3) When I originally configured this SP against our non-production 
Shibboleth IdP, its metadata does not have this url

<SingleSignOnService 
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" 
Location=............

It only has the last three listed above.

4) The vendor is also about the HTTP-POST and HTTP-Redirect binding, 
stating:

/For other IdPs we've worked with, those two bindings (HTTP-POST and 
HTTP-Redirect) are the same endpoint but you currently have different 
endpoints for different bindings. We would like to know which endpoint 
works on the current production IdP.//
/

Thanks,
Don

On 5/26/20 6:45 PM, Lohr, Donald wrote:
> I've another odd one.
>
> Working with a vendor to configure their SP.  They only 
> support/certify the following IdP's (Okta, Azure Active Directory, 
> Ping Federate, F5 and onelogin) and not Shibboleth.
>
> We have a non-production Shibboleth IdP server and I was able to get a 
> working configuration to login via this non-production Shibboleth IdP 
> and a test instance of their application, using a "IdP Initiated" model.
>
> On our non-production Shibboleth IdP it has a *https://* url style 
> entityID value that we made up when we build this server. On our 
> production Shibboleth IdP, it has a *urn:mace:incommon:* style 
> entityID value.
>
> Needless to say this vendor is not a InCommon member.
>
> I do not even know how to answer their questions as to why our 
> production Shibboleth IdP has a urn: vs a https: style entityID 
> value.  I have a whole bunch of other questions running in my mind I 
> do not even know how to ask.
>
> Sorry,
> Don
> -- 
> D o n a l d   L o h r
> I n f o r m a t i o n   S y s t e m s
> J a m e s   M a d i s o n   U n i v e r s i t y
> 5 4 0 . 5 6 8 . 3 7 3 0
>

-- 
D o n a l d   L o h r
I n f o r m a t i o n   S y s t e m s
J a m e s   M a d i s o n   U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200528/87f740fd/attachment.htm>