Author Topic: DocID Encryption  (Read 3884 times)

Marc

  • Newbie
  • *
  • Posts: 5
    • View Profile
DocID Encryption
« on: June 18, 2018, 08:17:30 AM »
In ODWEK 9.5.0.5 (and later), the DocIDs are encrypted. What we have observed is that the encrypted value is different between Linux and AIX and Windows servers.

What we need to know is: will the encrypted value remain the same for different Linux servers?
i.e. can you do a search on one Linux server, then pass the DocID to a different Linux server and do a retrieve?

Justin Derrick

  • IBM Content Manager OnDemand Consultant
  • Administrator
  • Hero Member
  • *****
  • Posts: 2229
  • CMOD Guru for hire...
    • View Profile
    • Tenacious Consulting
Re: DocID Encryption
« Reply #1 on: June 18, 2018, 10:33:40 AM »
The change should have been in v9.5.0.4, and anything newer.

If you want the old DocID back, you need to recreate it with another call:  ODFolder.recreateHit(<docid>)

-JD.
IBM CMOD Professional Services: http://TenaciousConsulting.com
Call:  +1-866-533-7742  or  eMail:  jd@justinderrick.com
IBM CMOD Wiki:  https://CMOD.wiki/
FREE IBM CMOD Education & Webinars:  https://CMOD.Training/

Interests: #AIX #Linux #Multiplatforms #DB2 #TSM #SP #Performance #Security #Audits #Customizing #Availability #HA #DR

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1200
    • View Profile
Re: DocID Encryption
« Reply #2 on: July 23, 2018, 05:30:11 PM »
I'm not an ODWEK guy at all but I know a little bit about this.


As Alessandro says elsewhere on these forums:

http://www.odusergroup.org/forums/index.php?topic=2233.msg9028#msg9028

Quote
...the docid for security reasons they use the user ID for the user requesting the docid to "encrypt" the docid.
So if userA gets a docid, and gives it to userB, then userB cannot use the docid, since he is not userA

The userid is also part of the encryption. 

This is described in the 9.5.0.3 readme

http://www-01.ibm.com/support/docview.wss?uid=swg27046127&aid=1
\
Beginning with 9.5.0.3 the document identifier generated by ODWEK
            has changed such that it is now encrypted and base64 encoded.
            Prior to 9.5.0.3 the document identifier had to be encrypted and/or
            encoded by the application before being used on the Web.

            Considerations:
              1) ODWEK will no longer generate the 'old' document identifier.
                Therefore any ODWEK application that leverages this 'new'
                document identifier must be at ODWEK 9.5.0.3 or later.

              2) ODWEK document identifiers are independent of the OnDemand
                 server.

              3) By default, ODWEK will no longer support being given the
                 'old' document identifier in which to recreate an ODHit object
                   - for example the recreateHit() api.
                 It is possible however to allow ODWEK to support accepting the
                 'old' document identifier.  This can be done by specifying
                 ARS_SUPPORT_OLD_ODWEK_DOCIDS=1 in the ars.cfg configuration
                 file for the OnDemand Server (in order to support this flag -
                 the OnDemand server must also be at a 9.5.0.3 or later.

              4) By default ODWEK will use an encryption key in which to
                 uniquely identify the OnDemand instance in which it is going
                 against (by default the OnDemand library server hostname and
                 port).  It is possible for a customer to override this key by
                 way of the setEncryptionKey() on the ODServer object.

              5) It is possible customers could see a decrease or increase in
                 the size of the 'new' document identifier compared to the
                 'old' document identifier.  Keep in mind that because it is
                 now encrypted and base64 encoded, comparing the sizes is not
                 a fair comparison.


Ed
#zOS #ODF