Zoho Help SP claims no metadata

[Baron Fujimoto]

This query string is coming from the SP? So these are items configured on the SP side of things?

What if the SP wants a specific attribute returned? A typical attribute-filter entry for them where it picks up the Requester value from the providerId for a PolicyRequirementRule?

Or if they want a specific NameIDFormat?

On Tue, Jun 16, 2020 at 11:51:28PM +0000, Nate Klingenstein wrote:
>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>
>
>

>-- 
>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


-- 
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum