Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1674

Allow override of table name on StoredId connector

    XMLWordPrintable

    Details

    • Java Version:
      Debian OpenJDK 11

      Description

      Hi,

      I've been experimenting with the samlSubjectID and samlPairwiseID attributes in 4.0.1 - and also consulting with the community.

      I see 4.0.1 so far covers these attributes in attribute-resolver-full.xml - which I could trace back to IDP-1306.

      In these examples, samlSubjectID is defined as a scoped version of attribute pointed to by idp.persistentId.sourceAttribute.

      And samlPairwiseID is defined based on ComputedId connector.

      I'd expect for a proper production-level deployment to store values in a database - so using StoredId connector.   And to properly support PairwiseID in parallel with existing use of EPTID/PersistentNameID, I assume one would have to maintain a separate database table for PairwiseID values.

      When searching documentation and code base (and code documentation), I found that JDBCPairwiseIdStore takes a tableName property ... however, to link this bean to an attribute definition, I had to bridge a rather wide gap.  I found that code already includes PairwiseID connector, which is however not yet covered in documentation.

      I got a working setup with the PAirwiseID connector and custom beans instantiating net.shibboleth.idp.attribute.impl.JDBCPairwiseIdStore (and net.shibboleth.idp.attribute.impl.ComputedPairwiseIdStore as dependency).

      However, for proper use, this would need:

      • Documentation on the PairwiseID connector (I assume this is in the pipeline)
      • Customizable beans that can be used with the connector - allowing to use BASE32 encoding and a distinct tableName while PersistentNameIDGenerator uses legacy BASE64 with shibpid table.

      To support samlSubjectID in hashed form and stored in database, it would be also highly useful to be able to reuse the code available for PairwiseID with a "fixed" SP identity - so that it produced a global (non-targeted ID), but otherwise does the same hashing / encoding / storing in database.

      I expect some of this is in the pipeline - but on suggestion from the community, I am submitting it as an explicit feature request.

      Please let me know if any of this needs further clarification.

      Cheers,
      Vlad

       

        Attachments

          Activity

            People

            Assignee:
            cantor.2@osu.edu Scott Cantor
            Reporter:
            tuakiriadmin-vmencl@virtualhome.tuakiri.ac.nz Vladimir Mencl
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - Not Specified
                Not Specified
                Logged:
                Time Spent - 1 hour, 45 minutes
                1h 45m