Zoho Help SP claims no metadata

[Nate Klingenstein]

Baron,

 
Typically on a query string, the AssertionConsumerService URL should be the shire parameter.  The target should be the RelayState parameter.  The entityID should be the providerId parameter.

 
Remote login URL: https://your.idp/idp/profile/SAML2/SSO

Remote logout URL: https://your.idp/idp/profile/Logout

Password Reset URL: You'll know

Key: Your IdP's public key, RSA

 
This is all as wonky as Scott says, yes.

 
 
Take care,

Nate.

 
--------

 

The Art of Access ®

 
Nate Klingenstein | Principal

https://www.signet.id/ 

 
-----Original message-----
From: Baron Fujimoto
Sent: Tuesday, June 16 2020, 5:37 pm
To: Shib Users
Subject: Re: Zoho Help SP claims no metadata
 
At the risk of sounding more dense, I see in the documentation where the relay state maybe configured via the target parameter, but I'm missing specifically *where* these unsolicited SSO endpoints should be configured. The examples in the Shibboleth docs aren't clear to me on this.

<https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration#UnsolicitedSSOConfiguration-RequestInterface>

I notice now that this UnsolicitedSSSConfiguration page is a child page of RelyingPartyConfiguration, but I don't find any identifiable guidance there either.

<https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration>

Nor on the page for the SAML 2 SSO configuration

<https://wiki.shibboleth.net/confluence/display/IDP30/SAML2SSOConfiguration>

On Tue, Jun 16, 2020 at 11:10:37PM +0000, Cantor, Scott wrote:
>The metadata belonging to the SP is invariant with respect to where SSO begins. There is nothing about the IdP in an SP's metadata regardless, and the SP's metadata would look essentially identical whether it supported requests or not.
>
>IdP initiated SSO is nothing more than a proprietary URL to tell the IdP to generate a response targeted to an SP. It's an unsigned request with limited features. There's nothing about it that involves metadata that isn't necessary in a normal case, which is, I guess, a good thing.
>
>RelayState is another matter. There should never be RelayState unless it comes from an SP and when it's imposed in such a case, the SP is doubly broken by forcing its local requirements on the IdP without simply implementing the standard to begin with. If they want RelayState, then they should issue requests containing it.
>
>Like most incorrect ways of using SAML, it's still supported; a target parameter to the IdP will produce a RelayState value matching it.
>
>-- Scott
>
>
>-- 
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net> 

-- 
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200616/02cbdba2/attachment.htm>