Migrated from Stored Persistent ID to Computed
Joshua Brodie
josbrodie at gmail.com
Mon Jul 30 21:03:30 EDT 2018
Hi Nate:
Thank you.
You are right -- it's not so simple as I had thought.
Challenge is we are receiving ora-08177 with the Oracle12C and stored
persistentIDs -- even with the retryableErrors -- can the following be in
anyway optimized?
<resolver:DataConnector id="myStoredId" xsi:type="dc:StoredId"
generatedAttributeID="persistentID" sourceAttributeID=
"%{idp.persistentId.sourceAttribute}" queryTimeout="PT5S"transactionRetries
="5" retryableErrors="72000 23000">
<resolver:Dependency ref="%{idp.persistentId.sourceAttribute}" />
<dc:BeanManagedConnection>OracleDataSource</dc:BeanManagedConnection>
</resolver:DataConnector>
On Mon, 30 Jul 2018 at 15:09, Nate Klingenstein <ndk at dewpoint.id> wrote:
> Joshua,
>
> It's not as easy to transition from stored identifiers to generated
> identifiers because you don't necessarily know what the state of the
> generator was when the original persistentId was generated. If you can
> guarantee that the salt is the same, the root attribute and its values are
> the same, and and none of the entittyID's has changed, then what you
> described should work.
>
> If you can't be absolutely certain the above conditions hold, then you may
> have zero or more stored identifiers that would be different from the brand
> new ones minted by the IdP.
>
> Unless there's a better way, I think you would want to match the generated
> values to the values in the database and look for discrepancies. If there
> are none, you can probably just flip the switch. If there are some and you
> want to flip the switch anyway, it becomes an account reconciliation and
> merger exercise.
>
> Hope I got you,
> Nate.
>
> -----Original message-----
> > From: Joshua Brodie
> > Sent: Monday, July 30 2018, 9:46 pm
> > To: users
> > Subject: Migrated from Stored Persistent ID to Computed
> >
> >
> >
> > We have had ongoing performance issues w.r.t Oracle and stored
> persistentID -- even with retry below.
> >
> > In moving from stored to computed -- are these the following 2 changes
> to make?
> >
> > SAML-NAMEID.PROPERTIES
> >
> > (the stored ID is the commented out lines)
> >
> > # Set to an empty property to skip hash-based generation of first stored
> ID
> >
> > idp.persistentId.computed =
> >
> > idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator
> >
> > #idp.persistentId.generator = shibboleth.StoredPersistentIdGenerator
> >
> > #idp.persistentId.dataSource = OracleDataSource
> >
> > idp.persistentId.sourceAttribute = uid
> >
> > idp.persistentId.salt = foobar+
> >
> > ATTRIBUTE-RESOLVER.XML
> >
> > STORED
> >
> >
> <resolver:DataConnector id="myStoredId" xsi:type="dc:StoredId" generatedAttributeID="persistentID" sourceAttributeID="%{idp.persistentId.sourceAttribute}" queryTimeout="PT5S"transactionRetries="5" retryableErrors="72000
> 23000">
> >
> >
> <resolver:Dependency ref="%{idp.persistentId.sourceAttribute}" />
> >
> >
> <dc:BeanManagedConnection>OracleDataSource</dc:BeanManagedConnection>
> >
> > </resolver:DataConnector>
> >
> > COMPUTED
> >
> >
> <resolver:DataConnector id="myComputedId" xsi:type="dc:ComputedId" sourceAttributeID="%{idp.persistentId.sourceAttribute}" generatedAttributeID="persistentID" salt="%{idp.ComputedIDDataConnector.salt}"/>
> >
> > --
> >
> > For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> >
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> >
> >
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180730/c4289143/attachment.html>
More information about the users
mailing list