<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 2/11/16 11:16 AM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:A5450B87-ED80-4E1B-9F9B-BA618FD7FD05@osu.edu"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">However, what would the configuration have to look like in case one

wants an IdP to respond to both these SPs (or rather all SPs it has

metadata for) with an entityID that is picked (from a list of entityIDs)

or computed based on information of the authentication request (e.g. the

Destination attribute)?

Is that possible by means of  configuration?

</pre>

      </blockquote>

      <pre wrap="">

Don't think so. There's kind of a mix of "static" and "dynamic" behavior in a lot of the properties, and responderId isn't a function entry point, just a static String property.

We'd have to build in an injection point for that I guess to make it a function.</pre>

    </blockquote>

    <br>

    <br>

    Aside from a new Function-based approach: If the desired task is to

    select a RelyingPartyConfiguration (including responderId) based on

    something other than the entityID, like info in the SAML request,

    couldn't this be done today pretty easily by just attaching

    different activationCondtion(s) to the RPC, as a

    Predicate<ProfileRequestContext>.  I thought that was the

    whole point of the v3 DefaultRelyingPartyConfigurationResolver impl,

    it just loops over the RPC's in order and takes the one(s) that

    match the predicate (with usually only the first one really being

    used by most things).<br>

    <br>

  </body>

</html>