StoredID Canonicalization, DataSources, configuration & code structure

[Rod Widdowson]

I'd like to poll for opinions, particularly Daniel's, about this...

A major aim of the SubjectC14N work currently ongoing is to allow us to
deprecate the <PrincipalConnector/> Stanzas in the Attribute-resolver.xml
file.  This work is panning out quite nicely.  Or it was until I looked at
the StoredId Prinicipal and Data Connector.

The way that these are configured in V2 [1] is that the StoredId
PrincipalConnector definition references the StoredId DataConnector which is
issuing the persistent identities.  Because these are both in the same file
this makes for a simple, safe and fool proof configuration.  The StoredId
PrincipallConnector can reach into the StoreId DataConnector and get hold of
the StoredId store is it using and all is good.

However in the brave new world the C14N is not normally going to be defined
in the same file and hence we cannot "just" pass the reference around.  

I suppose it might be possible to hack this by requiring that the parser for
the StoredId Connector inserts a reference into the parent context, but this
is a hideous abuse of hierarchy and I am not even sure whether it is
possible particularly given the one way air-gap which is introduced by
reloadability.

Rather, I should like to suggest that we allow external configuration of the
javax.sql.DataSource bean which is summoned up by a
<ApplicationManagedConnection> or a <ContainerManagedConnection>.  Given
this, the StoredIdConnectors, RDBMSConnectors and the C14N code can share
database connections cleanly.  This is in some ways an extension of the work
that Daniel has already done which allows the Spring-bean definition of
XXXManagedConnections.  This would require some backwards-compatible
extension of the data connector schema to allow reference to the externally
defined DataSource inside the attribute-resolver.  We could also allow
definition of a <ApplicationManagedConnection> and
<ContainerManagedConnection> inside separate files.

The idea is that a DataConnector might look like this:

<resolver:DataConnector ....>
      <resolver:Dependency .../>
      <ExternalConnection ref="ConnectorId"/>
<resolver:DataConnector/>

And in the separate file we could have either (and more usually) spring
beans defining the (identified) DataSource or an (identified)
<XXXXManagedConnection>.

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

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.

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.

Thoughts?  Comments?

[1]
https://wiki.shibboleth.net/confluence/display/SHIB2/StoredIdPrincipalConnec
tor