Access to peer endpoint via scripted attribute resolver

[Cantor, Scott]

On 5/12/16, 1:51 AM, "users on behalf of Dave Goldhammer" <users-bounces at shibboleth.net on behalf of dave.goldhammer at Colorado.EDU> wrote:



>
>Scott, thanks for your reply. I was eventually able to access the
>peer endpoint URL once I figured out that the SAMLEndpointContext is
>a child of the SAMLPeerEntityContext and that I needed the outbound
>message context.

Correct, I was thinking backwards, sorry to waste your time on that.

>I started down this path as a result of an interesting request from
>our Salesforce team related to licensing and user roles within the
>application. They asked if we could modify an existing attribute when
>a user logs on to a particular SP.

You absolutely should not do that based on endpoint.

> From the IdP perspective, there
>is a single Salesforce entityID with multiple endpoints defined in
>the metadata. Adding another distinct Salesforce SP with a different
>entityID creates some challenges from the Salesforce side of things.

That's too bad for them, but it doesn't change the model.

>Scott, would you be willing to elaborate on why this would be a bad
>idea, as you noted in your original reply below?

Endpoints are an implementation detail and are not stable values. They can change for all kinds of reasons. The entire point of using naming is to allow for policy to be independent of implementation details that can change for technical reasons.

-- Scott