12 Replies Latest reply on Apr 14, 2011 2:35 PM by Ricardo Av-Oracle


      Please can you tell me the required format of "publickeydata" that needs returning in the following response?

      ; Public key
      <Property name="PK">


        • 1. Re: GetProperties/PropertyName="PK"
          Get PK is handled in the ISDK 20 core.
          You need to register the action inside web.xml if it is not there already.
          Verify or add this to web.xml, where other DMS actions are defined.


          The get PK request then will be handled by above class.

          • 2. Re: GetProperties/PropertyName="PK"
            What do we do if we're not using ISDK 20?

            • 3. Re: GetProperties/PropertyName="PK"
              Even I am interested in finding out the format of the key, I tried the x509Certificate Public key both with Base64 encoding and without, but AutoVue server does not seem to like it.

              Also it will good to know if DMAPI are fully supported or not, it seems that focus is pretty much on ISDK
              • 4. Re: GetProperties/PropertyName="PK"
                Also need information and clarification on this new PK get property request.

                Horrible documentation - and as far as I can tell there is no way past this in api version 20...

                We use single sign on mode - passes our authentication cookie from the main app which is already just a magic token...no encryption necessary since nothing sensitive is passed.

                One place in the DMAPI doc implies that not providing the key in response to the request should disable encryption -- but just like the key format (and encryption algorithm) are not documented, neither is the "right" way to answer "no key, thanks"

                Fortunately, uncommenting *#dms.vuelink.version=19.3* in jvueserver.properties gets you passed this...for now.
                • 5. Re: GetProperties/PropertyName="PK"
                  Ricardo Av-Oracle
                  Some clarifications
                  the Public key exchange is only required if you are not authorized to use a resource (ie forwarding cookies is not enough to get you in your system or you do not have the cookie)
                  The PK result is a BAse64 encoded version of the public key result send by the JAVA JCE subsystem see java.security.Key.getEncoded() (http://download.oracle.com/javase/1.4.2/docs/api/java/security/Key.html#getEncoded%28%29)
                  As a secure deployment requires some preparation (make sure your seed and random number generator are properly initialized, etc) all that support has been properly packaged inside the ISDK (code that comes with samples on how to implement an AutoVue integration)
                  Now if you prefer doing it the hard way, nobody will prevent you from doing it
                  but should issues arise, support is limited and a good dose of experience is a MUST
                  Also if you are trying something and expect an answer, you will need to attach relevant information (server logs with the required verbosity)
                  Usually reading the logs will give you an indication of what is wrong
                  Also, as with any software, telling which version you are developing/integrating is a valuable information
                  since some solutions may work on one version but not others
                  Unsecure deployments can not be supported (I believe that can be easily understood)
                  Hope this helps
                  1 person found this helpful
                  • 6. Re: GetProperties/PropertyName="PK"
                    PK must be the public key generated using Diffie-Hellman Key Agreement

                    I think this might help some one implementating DMAPI

                    When you get following Request:

                    <?xml version="1.0" encoding="UTF-8"?>
                    <Property name="PK"></Property>

                    Return following response from your code

                    <SUCCEED code='0' message='Returning properties'></SUCCEED>
                    <Property name='PK'> <![CDATA[MIIBpTCCARoGCSqGSIb3DQEDATCCAQsCgYEAjdgPnWteVdMz9Yqw6ixTirDZO4DmpPoLyWYb+NT1wwsSc4F3+1IOjSBLLVuD4G/b+dfmLIu5c832lhDioUFnLgNzp2dmQ31uJDRHS1FFO8g9Qr/rD33hJ67NzHcozIUbEqBl+LqCF2U4SQD6BT+L+CxNQYXlPXH32v6lWhlqf60CgYA1tdDhHpbqhfXSF2BfVVt5/IvLnt8ckAptqHXOyWqIbAKaloPPcCg4KnkIfHB8ASNiDFjb6OgqDtM3VHSrjkhpwzX8XRXBypv8+OlJkN5G7YMe+8y4U8+xX+62n43/C6aR05fVF8QIDJpXIboSV4CI1Uw67Au6oi+F1W8ceXuWTwICA/8DgYQAAoGADMRCvZ++pVfB01tNxuKgN9egoC1aWjx8zDExnDrZHmozPA7ilrRleufgmIkPqpzUT32Pt75PFuwFhzwIcOUika2TkuTz//kSFP1GDZ6opNQRLDIbbz5Wv0PAUnUEEy3oTgp1Cj/p/w++9rBqER1VA2Vw/MZYPuySbkfD+r6si/E]]>

                    and in your next request you will get your Auth block encrypted as follows(See the Key attribute in the <Authorization> element)

                    <?xml version="1.0" encoding="UTF-8"?>
                    <Authorization KEY="MIIBpTCCARoGCSqGSIb3DQEDATCCAQsCgYEAjdgPnWteVdMz9Yqw6ixTirDZO4DmpPoLyWYb+NT1
                    <Property name="CSI_UserName"></Property>

                    I used following code to generate the Key

                    import java.security.AlgorithmParameterGenerator;
                    import java.security.AlgorithmParameters;
                    import java.security.KeyPairGenerator;
                    import java.security.KeyPair;
                    import javax.crypto.spec.DHParameterSpec;
                    import com.cimmetry.vuelink.io.Base64;

                    public class Main {
                    public static void main(String[] argv) throws Exception {

                    AlgorithmParameterGenerator localAlgorithmParameterGenerator = AlgorithmParameterGenerator.getInstance("DH");
                    AlgorithmParameters localAlgorithmParameters = localAlgorithmParameterGenerator.generateParameters();
                    DHParameterSpec localDHParameterSpec = (DHParameterSpec)localAlgorithmParameters.getParameterSpec(DHParameterSpec.class);

                         Object localObject = KeyPairGenerator.getInstance("DH");
                    KeyPair m_keyPair = ((KeyPairGenerator)localObject).generateKeyPair();

                         byte[] keyPairBytes = m_keyPair.getPublic().getEncoded();
                    String str = Base64.encode(keyPairBytes);


                    I have not been able to generate the above key with .NET's DH Implementation :(


                    Edited by: 810129 on 07-Apr-2011 03:37
                    • 7. Re: GetProperties/PropertyName="PK"
                      Wow. First and foremost, thanks for the two answers - I was really not expecting any response. The information provided gives me enough to give this another try. I suggest that information be added to the official documentation.

                      But I can't resist bantering this around a bit more...

                      One more thing before I get started: Spitfire knows its place in the ecosphere. We are barely a blip on the Autoview product radar and a meaningless anomaly on the greater Oracle radar….

                      For positioning on that radar, Spitfire’s DMS implementation does not use the (DMS side) ISDK core – we have implemented our own DMS handler. I get the impression from others that posted on this thread before me that we are not alone in not using the ISDK. It should not matter, but our DMS side is written in .NET. I’ve lost track, but the DMS implementation is over 5 years old and has been responsible for someplace in the range of 50-75 Autoview sites each with a varying number of seats.

                      Now to get started:

                      We are running client and server v20.1

                      Ricardo said “the Public key exchange is only required if you are not authorized to use a resource (ie forwarding cookies is not enough to get you in your system or you do not have the cookie)” – this does not seem to be true. The very first DMS request we receive is the GetProperies PK. At this point the client side parameters seem relevant, they are:

                      <PARAM NAME="CACHEUI" VALUE="true">
                      <PARAM NAME="EMBEDDED" VALUE="true">
                      <PARAM NAME="VERBOSE" VALUE="false">
                      <PARAM NAME="FILENAME" VALUE="http://STANY2006/sfPMS/sfImg.ashx?key=e053fb13-9911-44c2-9703-132b0dea3f44&type=.TIF">
                      <PARAM NAME="DMS" VALUE="http://STANY2006/sfPMS/sfDMS.ashx">
                      <PARAM NAME="DMS_PRESERVE_COOKIES" VALUE="sfSession">
                      <PARAM NAME="JVUESERVER" VALUE="socket://SFQA2:5099;socket://SFWBNT:5099;http://STANYLAP09/servlet/VueServletIsapi.dll">
                      <PARAM NAME="ONINIT" VALUE="onAppletInit();">

                      And, in 19.3 compatibility mode, the first DMS request is


                      I assure you that the only data I need is that sfSession cookie. It contains no sensitive information.

                      Which leads me to Ricardo’s statement that “Unsecure deployments cannot be supported”…okay, but let’s also keep perspective: Security can be implemented and addressed in many layers: SSL provides encrypted security and most of our DMS PARAM URLs use HTTPS… so, thanks, but I don’t think your API needs to unilaterally and irrevocably enforce security. (It is okay to require the PK handshake, but should support a "no thanks" mode - see question 2 below)

                      All that aside, back to my one already meaningless authentication cookie – there is nothing in my DMS handshake that I would agree needs encryption.

                      So, the outstanding questions are:

                      1) Why is there a GETPROPERTIES PK handshake when there is nothing to encrypt? Is this doing what you expect, or is something else not working?

                      2) Is there any response to the request for the public key that disables the encryption? This is implied by page 54 of http://download.oracle.com/docs/cd/E16931_02/otn/pdf/E16865_01.pdf that states “If a valid public key is returned, AutoVue will use it to encrypt entire Authorization block”…the implication being that if a valid public key is not returned, AutoVue will not encrypt…

                      3) Why is the DMAPI manual (link above) no longer included in the DMS distribution?

                      On my side, I will be trying to use the information from Ketul and see if I have better luck coaxing .NET to do the DH key and decryption work….
                      • 8. Re: GetProperties/PropertyName="PK"
                        Warren Baird-Oracle
                        3) Why is the DMAPI manual (link above) no longer included in the DMS distribution?
                        I'll let others who are more qualified answer your other questions - but I can take this one. We are actively discouraging people from using the DMAPI - since our ISDK now provides a web services API layer, it's a lot easier to implement integrations even from .NET using the ISDK. It's also more future-proof, integrations based on the ISDK will be much more likely to work out of the box with future versions of AutoVue, and in the worst case should only require minor tweaking.

                        We don't guarantee that the DMAPI itself won't change substantially in future versions - using the ISDK will isolate you from those changes.

                        If you can't move your integration off the DMAPI for now, we can provide you with the most recent copy of the DMAPI manual. Contact me if you'd like this - you can figure out my email from my handle on the forum - using a firstname.lastname@oracle.com pattern.

                        1 person found this helpful
                        • 9. Re: GetProperties/PropertyName="PK"
                          Graham Mckendry-Oracle
                          Also, almost entirely off-topic for this thread, but I noticed your JVUESERVER applet parameter is attempting two different socket connections and then a VueServletIsapi connection. That will need to be updated, since:

                          - Direct socket is no longer supported (see Oracle KM Note 1059139.1 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=1059139.1)
                          - VueServletIsapi is no longer supported (see Oracle KM Note 1059147.1 https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=1059147.1)
                          1 person found this helpful
                          • 10. Re: GetProperties/PropertyName="PK"
                            user11031847 from Spitfire (Sorry don’t know your name!) We are also using or rather intended to use DMAPI in the same fashion as you have been using i.e implement a .NET Handler for Microsoft Based DMS instead of going through the longer/complex route of VueServlet --> ISDK Implementation or AutoVue’s Web-Service Client (webclient) --> SOAP .NET Services -->SharePoint or other Microsoft based Bespoke DMS

                            Its disappointing Oracle AutoVue is not really recommending use of DMAPI which is based on a much faster & cleaner Xml request/response architecture without the overhead of extra Servlet hop and SOAP communication.

                            SOAP is probably slowest form of inter application communication and was probably never designed to deal with larger files and hence protocol such as MTOM came into existence, Anyone who has dealt with MTOM and .NET SOAP Web-service knows its implementation is anything but straight forward.
                            Warren Baird wrote:
                            We are actively discouraging people from using the DMAPI - since our ISDK now provides a web services API >layer, it's a lot easier to implement integrations even from .NET using the ISDK.
                            I am not sure how many actually implementations actually uses BluePrint.wsdl (AutoVue’s Web services for ISDK) but before we went to DMAPI route we did try to use the supported Web-service API first and here is my first-hand experience from a *.NET developer perspective*:

                            -- WSClient Application that comes with ISDK is with full source code and not compiled so first you would need to download some java IDE like NetBeans to compile it

                            -- Just could not get the basic communication going between Wsclient and .NET Web-Services until I did following after spending few days debugging through the wclient source code:

                            1) Delete the BluePrint proxy classes that comes with wsclient and re-generate a new proxy with latest Version of NetBeans (which presumably uses latest version of JAX-WS)

                            2) Disable MTOM & Authentication completely (Read – Comment the code out from wsclient)

                            -- Also the documentation says only 4 methods are needed to implement a basic read action but actually you need to implement 5 methods to do a basic read operation.

                            Obviously using DMAPI directly with .NET Handler was much cleaner Architecture than the above messy implementation.

                            I am sure someone with tons of Java experience would find it lot easier to deal with Web Service API in ISDK.

                            • 11. Re: GetProperties/PropertyName="PK"
                              GrahamOracle wrote:
                              Also, almost entirely off-topic for this thread, but I noticed your JVUESERVER applet parameter is attempting two different socket connections and then a VueServletIsapi connection. That will need to be updated...>
                              Thanks, Graham.

                              Caveat here is that the PARAM snippet was from a DEV system used to connect and test our DMS compatibility against various servers, way back to v19. I think we are done with v18, at least I hope... Can't seem to get all client sites to update at the same time. Image that!
                              • 12. Re: GetProperties/PropertyName="PK"
                                Ricardo Av-Oracle
                                19.3 compatibility mode will not encrypt the authorization xml section
                                We can argue about whether that is sensitive information or not, but out of anybody guess, the answer is generally you do not know
                                and without prior knowledge assuming nothing important (ie password) is sent is just a BUG
                                Now, the importance is not whether that section is encrypted or not, for authentication purposes if you rely on a cookie, that cookie should be in the http headers
                                (if that is the case, we strongly recommend https)
                                As with everything, a radical change can not happen over night, and tightening everything in a singkle release will just be too disruptive
                                So AV did it in multiple passes, giving ample warning to people to update and migrate
                                There is also a path that makes it easy to update (just drop a new isdk jar)
                                Now, that does not suit everybody and some help is required sometimes anyway

                                Going back to the handshake, if the only thing you need is an SSO cookie, then the procedure is simple
                                (you have it already) set the DMS_PRESERVE_COOKIE=my_cookie applet param (introduced in AV20, as a security measure, you do not always want/need all the cookies floating around) but that comes with extra work : you need to identify what cookies are required
                                Now, since those cookies are also passed in the Authorization section and you do not have prior info about it, they are considered sensitive info and encrypted
                                Simply put, not all people will use http and yes, cookies have sensitive information (does firesheep and facebook ring a bell?)
                                The logic is, if you are not in 19.3 compatible mode, and the section you forward is deemed sensitive, a public key handshake will be initiated
                                IMPORTANT: 19.3 compatibility flag is disabled by default in 20.1 and will be removed in the next release
                                If you are handling the PK property, the handshake continues
                                if not (error or empty value) it will try to proceed without it (error is logged)
                                That behaviour will change in subsequent releases as the expected behaviour is that is should fail (otherwise security is bypassed)
                                So your best option is just to handle it
                                Also as a note, there is no constraint on which protocol to handle (it was stated previously that DH is required, but as long as both JRE or JRE .net have the same handshake protocol, it will work)
                                On your side, make sure the serialization of the PK is the same as on the JAVA side (std x509 with proper headers telling which format follows, but that is JAVA JCE implementation specific that you will need to review and write a compatible .NET wrapper for it)
                                Again, server logs are your friend ...
                                Hope this clarifies some issues
                                1 person found this helpful