StoredID Canonicalization, DataSources, configuration & code structure

[Cantor, Scott]

On 1/30/14, 6:16 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>And in the separate file we could have either (and more usually) spring
>beans defining the (identified) DataSource or an (identified)
><XXXXManagedConnection>.

I would think in the end that would be best anyway, since it finally
solves the problem of sharing application-managed connections across
connectors, which is better for pooling.

>In order that these definitions be sharable between the StoredId C14N and
>the StoredId DataConnector they would need to be defined at a parent
>level,
>and hence they would not be reloadable (unless we implement hierarchies of
>cascading reloadability which thought makes me shudder).

I think this is fine as long as we're not removing the option to declare
them locally within the resolver as we do now. It doesn't even break the
resolver itself reloading, right? If the data connection is outside that
context, it doesn't get flushed by a reload, which is fine for most cases.
Changing or adding attributes rarely involves changing data sources and
that's a fairly radical change to make on a reload.

>As far as code structure: C14N is implemented in a different module from
>Attribute Resolution (idp-saml-impl and idp-attribute-resolver-impl), and
>the latter module depends on the former.  Thus the current structure in
>which the classes which the StoredID connectors depend upon (PersistentId
>and PersistentIDStore) are defined in idp-attribute-resolver-impl doesn't
>work.

I more or less expected that (but I wasn't sure if the resolver-impl
module actually depended on the saml module. Does it actually depend on
saml-impl? We probably don't want that...

>The structure I think I am going to adopt is to move the PersistentId to
>idp-core and to add an interface there to describe the work of the
>PersistentIdStore (but made non-database specific).  This then leaves the
>problem of the location of the PersistentIdStore.  I do not believe that
>it
>belongs in idp-core, and it somehow feels wrong that it be in
>idp-saml-impl.
>However it cannot stay in idp-attribute-resolver-impl  (because of
>dependencies) and I cannot see where else to put it.

I think it belongs in saml-api if it's an actual API. Persistent IDs are
for all intents and purposes SAML-specific, and if they ever become more,
we can refactor then.

-- Scott