alternate attributeSourceIDs for a given nameid format

[Baron Fujimoto]

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.

I think the base reference for this is <
https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration>.
But in the Examples section, "Given an SP named '
https://sp.example.org/shibboleth', 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.

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?

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                p:attributeSourceIds="#{ {'attrEmail_aberrant'} }"
            <property name="activationCondition">
                <bean parent="shibboleth.Conditions.RelyingPartyId"
c:candidates="#{{aberrant_entityID}}" />
            </property>
        </bean>

       <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
            p:attributeSourceIds="#{ {'attrEmail_normall'} }" />

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?



On Tue, Mar 9, 2021 at 4:42 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

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


-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210310/6d74bc3e/attachment.htm>