Last week on the February Documentum User Group I asked about D2-Config and its lack of integration with OTDS (Is this the only Documentum web application not supporting OTDS?) and as I didn’t get an answer, I decided to take this as a nice exercise (Although most of the work was done by José Ramón Marcos). So, let’s go 😀

First step is quite simple, grab the OTDS authentication class from DA / Webtop and move it to a filter, what you basically need is the buildAuthenticationRequestAndRedirect method (by checking the code you should be able to understand the logic behind this).

Add the filter to D2-Config (I suggest to filter /*), then you’ll need some workarounds to make this work properly. In our case, by using morlex programming, we created an index.jsp page that would be the landing page from OTDS and that will handle the “advanced features” explained later. This JSP just receives the token from OTDS as an anchor and process it to send it to the ConnectDialog.html static page.

Finally, we need to modify ConnectDialog (as you wish) to not load the username/password fields / hide them or whatever, and some JS to pass the user (‘null’, as this will be extracted from the token on server side) and the token (dm_otds_ticket=<token value>). And:

This works fantastically well, however, someone might ask for being able to login as another user (dmadmin). We’ve already seen some bizarre and unsecure attempts to provide this functionality, but can we do something better? Let’s see:

We will take a look at JMS’ OTDS Authentication class, and grab the getUserNameFromToken method. You’ll need the OTDS’ certificate used to configure JMS OTDS authenticator servlet, which we can add to a custom properties file that we can use as well to add a preconfigured list of “premium” users that will be able to login as other user… after going through OTDS authentication (so not open to anyone passing by, unlike other “solutions”). Once this is done, we will call this method from our JSP to retrieve the user logged in OTDS and check if it is a “premium” member:

Aaand magic, there you have a quite secure approach to allow users (previously authenticated) to use an alternative login. Wasn’t that hard OT, was it?

Today we have another case of a “difficult to understand” approach from OT regarding security. You probably know that basic security sugesstions include moving from user/password authentication to 2FA/SSO as these are more secure.

If you have experienced/used this approach before (and specially if you’re a “power user”) you might have missed the possibility to login as a different user (=dmadmin) for very specific, not common tasks. Well, OT seems to have found a solution for this: skip_sso (or skip_security) parameter:

What’s wrong with this approach? Let’s see:

1. You offer the possibility of a more secure authentication mechanism (2FA/SSO) and you destroy that by providing a way to override it.
2. skip_sso can’t be disabled (or better said, this should be a disabled by default feature that could be enabled for certain user cases, as the documentation states “in some cases”, not for every single user!)
3. skip_sso can’t be limited to specific users (so everyone can access via user/password regardless of the configuration)
4. Not only you’re not simply falling back to D2 login screen (which could be “adapted” via CSS to hide the user/password field), you’re directly allowing to login into D2 blocking any option to stop this.
5. In the cloud, you’re opening you repository to anyone that knows the default password for certain users that are not changed automatically and that are present in every repository
6. Man in the middle attacks are celebrating this skip_sso parameter, as well as anyone running a network sniffer (I’m quite sure cybersec departments will be “happy” to see urls with “username” and “password” paremeter flying through the network)

So, with this clear security failure on mind, what can we do to improve the situation (on an on-premise environment, as we will be losing any change done to D2 container on restart)?

1. Create your own filter, dropping this parameter if detected (As the original filter is converted to JS due to GWT, we can’t simply “override” it). You’ll need to drop you custom class and modify web.xml to include the filter
2. Do not drop the parameter, but put some more effort on the code, adding some parameter to D2FS/settings.properties where you indicate exactly the users that can use this feature, effectively blocking any other user from using this. Still you need to code this. And modify the original D2.war

The experimental preview of the D2 SmartView SDK is finally available to download. This comes packaged as a zip file containing the SDK, which is a combination of Maven, NPM and NodeJS (not the most attractive combination for Documentum old-timers :D)

So, once we get the zip file, we can do the following to install the SDK:

mkdir sviewsdk
cd sviewsdk/
mv ../d2/smartviewsdk.zip .
unzip smartviewsdk.zip

chmod u+x *.sh
sudo apt-get update
sudo apt install maven
mvn -version

sudo apt install nodejs
node -v

sudo apt install npm
curl -sL https://deb.nodesource.com/setup_14.x | sudo bash -
sudo apt-get install -y nodejs
node -v

sudo npm install -g npm@latest
sudo npm install -g grunt-cli

./ws-init.sh

As the “supported” NPM versions are 12-14, we should manually install 14. You should now run “npm update” to make sure everything is, well, up to date. Then you can launch the documentation by running “npm run documentation”

d2sv-sdk@22.4.0 documentation
node ./utils/doc-server.js

Starting documentation server at http://0.0.0.0:7777

And if you open localhost:7777/sdk:

After reading through the documentation, we should try to run the “workspace assistant”. For this, I had to manually run the following command as the ws-init script didn’t work properly: “sudo npm run postinstall”. After this, you can run the start command “npm start”

d2sv-sdk@22.4.0 start
node ./utils/run-generator-cli.js interface

And you’ll see the “assistant”:

You can browse through the options to see what’s available. For this first test I opted for using the included examples and then compiling them:

After this, I copied the resulting jar file artifact (on the “target” folder, and not the “dist” folder, as the documentation wrongly states) to Smartview and… Smartview no longer starts 😀 So I guess I’ll have to keep investigating… good luck