Extending ResolverStoredIDDataConnector

[Alistair Young]

> No, that is not considered part of the public API and hence has not
> external documentation
how do I know what to munge to? i.e. what to put in the fields for ResolverStoredIDDataConnector?

Alistair

-- 
mov eax,1
mov ebx,0
int 80h




On 11 Jun 2012, at 12:52, Chad La Joie wrote:

> On Mon, Jun 11, 2012 at 7:47 AM, Alistair Young
> <alistair.young at uhi.ac.uk> wrote:
>> I'm looking into migrating to the shib IdP 2.3.6 but already have a database of ePTID values. Is it possible to register your own connectors, such as an extended ResolverStoredIDDataConnector to deal with the legacy database?
> 
> Yes.
> 
>> Or would it be better to munge the legacy database to the format required by ResolverStoredIDDataConnector?
> 
> This is the approach I would take.  This would be a one-time
> conversion whereas if you're creating a custom data connector you'll
> have to test that with every release.
> 
>> All existing ePTID values for user/idp/sp triples have to be maintained but I presume ResolverStoredIDDataConnector won't generate new ones if it sees them in the database and the deactivationDate hasn't been reached?
> 
> Correct.
> 
>> Also, is there a doc stating how the fields are used? e.g. is it principalName or localId that corresponds to the 'user' when looking for an existing ePTID value?
> 
> No, that is not considered part of the public API and hence has not
> external documentation.
> 
> -- 
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net