<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I'm afraid my grasp of IdP-initiated SPs is poor and I don't yet have an inkling how we might begin to implement these possibilities without more explicit documentation or examples.<div><br></div><div>I think the base reference for this is <<a href="https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration">https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration</a>>. But in the Examples section, "Given an SP named '<a href="https://sp.example.org/shibboleth">https://sp.example.org/shibboleth</a>', requesting SAML 2.0 SSO to the SP's default endpoint in metadata is just a link to: [sample URL]", I'm not sure whose metadata is being referred to, nor where the example link is actually used. We don't have any real visibility into how the SP is setting things up on their end.</div><div><br></div><div>Getting back to the original suggestion by Gary Lipscomb, may we can kludge that after all, assuming we can have multiple SAML2AttributeSourcedGenerator beans in saml-nameid.xml that use result in the same nameid format, but use different attributeSourceID. If so, would these beans be order dependent on a first match basis (like metadata?). Ie. something like this?</div><div><br></div><div><div>        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"</div><div>                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"</div><div>                p:attributeSourceIds="#{ {'attrEmail_aberrant'} }"</div><div>            <property name="activationCondition"></div><div>                <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{aberrant_entityID}}" /></div><div>            </property></div><div>        </bean></div></div><div><br></div><div><div>       <bean parent="shibboleth.SAML2AttributeSourcedGenerator"</div><div>            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"</div><div>            p:attributeSourceIds="#{ {'attrEmail_normall'} }" /></div></div><div><br></div><div>If that would work, then perhaps we just need to be able to synthesize the attrEmail_aberrant attribute source appropriately? We may be able to do this based on our other existing attributes, but I think we would need a many-to-one mapping for the resulting attrEmail_aberrant attribute since the attribute used as an input to the definition may be multivalued. Would this require a ScriptedAttribute definition?</div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 4:42 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">There is a second trick I've used, arguable that it's any more palatable, but it allows you to override the entityID of an IdP-initiated SP.<br>
<br>
Even if Concur checks the audience restriction condition (that's a big if), you can fool them by using an alternative entityID in your requests into the IdP and then add back their real entityID as an additional audience using the profile option that populates additional audience values. So they get the real entityID in the assertion but you can can trigger policy on the fake one.<br>
<br>
-- Scott<br>
<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> :: UH Information Technology Services<br>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum</div></div>