State of SecurityConfiguration APIs in idp-profile-api

[Cantor, Scott]

On 12/12/13, 5:04 AM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>First, the underlying constituent -Configuration interfaces of which it
>makes use are:  As you may remember, we split that original "security
>configuration" concept into static "configuration" and runtime
>"parameters" classes.  I think the parameters ones are pretty set, but
>the configuration ones less so (e.g. not sure about the presence of the
>credential and algorithm URIs on the EncryptionConfiguration).

The classes I looked at were the Configuration ones, mainly.

>But mainly I'm not sure of the when/where/how of the usage of this
>actual idp-profile-api SecurityConfiguration class.  I thought probably
>this was intended to drive per-RP security config.  But is this intended
>to be something that hangs off of something in the relying-party.xml
>(e.g. a profile config), or is it a separate layer/config file, etc?  I
>can't recall that we've really hashed that out yet (or I've forgotten).

In terms of exposure to the code, yes, it's currently hanging off the
ProfileConfig, so access is by way of RelyingPartyContext through to that
structure.

As far as how it gets configured, I think that's TBD and fungible, I don't
really want us to map one to one between configuration relationships and
API relationships, which is somewhat connected to my note of yesterday,
though not exactly the same issue.

Anyway, it sounds like at least the IdP layer code is definitely not
baked, unsurprisingly.

-- Scott