CDR Tickets

Here's a list of things that will need to happen for this ticket:

1. Get the list of NIH domain accounts for each active CDR user account, mapped between the names for the corresponding accounts

2. Populate the win_usr table using the mapping from the first step

3. Install the version of the CDR server which accepts the WindowsName parameter in the CdrLogon command - DONE (DEV)

4. Modify the HTTPS tunneling wrapper to prevent bypass of Windows authentication for outside requests - DONE (DEV)

5. Replace the existing CDR login form and CGI script with a protected CGI login script which triggers authentication using NIH domain account credentials

6. Modify the CDR client loader program to log in using the script installed in the previous step, and to create a new session using the WindowsName parameter of the CdrLogon command

7. Modify any scripts which need to redirect to the new login page instead of the current form

8. Modify CDR server's user account commands to incorporate NIH domain account name

9. Modify Python wrappers to incorporate NIH domain account name

10. Modify interface for user maintenance to add field for NIH domain account name

What have I left out?

I have attached a spreadsheet with the list of CDR users who are still active on PROD (excluding machine accounts, for mailers, publishing, etc.).

Please fill in the column for the NIH login names. Also, please identify any accounts which should be marked as no longer active.

I have attached a spreadsheet with the list of CDR users who are still active on PROD

Deb Price and Bret Youngquist are no longer active.

We've got a decision to make for this ticket. We can either:

1. keep the existing CDR user names, and map the NIH domain account names to them; or

2. use the NIH domain account names as the CDR user names (for those CDR accounts which are not machine accounts).

The advantage of the first option is that the user attributes on Comment and ResponseToComment elements would still match the CDR user names. The advantage of the second option is that users would have only a single account name to keep track of. If we adopt the second option, we can either leave the existing user attributes alone, or we can run a global change job to switch the values to match the new user names (though a global change would not affect the values in all the older versions - we'd need more elaborate custom software to do that).

My recommendation would be to adopt the second option (use the NIH login name for non-machine accounts), and to leave the attributes on the Comment and ResponseToComment elements alone.

With this option, we would drop the new win_usr table which would have been used for the first option, and NULL out the password columns for non-machine accounts.

In either case, we will be inactivating non-machine accounts which are not associated with individual users (for example, the guest account we set up for CBIIT, or the CIAT temporary account).

I believe I've added as watchers the interested parties who might want to weigh in on this decision.

Please let me know your preference.

I think it makes sense to keep the CDR user names and map existing NIH accounts to them. Although most of the NIH usernames are easily decipherable, some are a bit less so. This also gives us the advantage of consistency with regard to comment attributes in the system.

Here's an updated spreadsheet with the OCPL NIH usernames filled in. William, could you add the NIH usernames for CIAT staff? Thanks.

Hey Bob, What's the LOE for Options 1 and 2? I would think it would make maintenance easier in the future if the usernames match the NIH usernames.

Not a huge difference in the LOE for the two options. If we go with the first option I'll need to modify the protected CGI login script to return the CDR user name along with the session ID, so it can be passed on to the DLL, but that's maybe another 1/2 hour at most. There would also be more work to modify the CDR client-server APIs (and Python wrappers and the Admin CGI) that deal with user accounts to take care of the two account names, maybe another hour or two. There might be some other things that would be trickier in the software if we have two sets of user names, but I can't think of any right now. Biggest penalty I can think of if we go with the first option is dealing with users who get confused about which account name does what.

I have attached an updated spreadsheet with all CIAT users domain accounts entered.

Either approach is fine with me. Relying on the NIH account names might cause a little more confusion in some areas and a little less confusion in others - especially in the long term as more and more NIH systems rely entirely on NIH account names.

I see that I mistyped in my earlier comment, where I said I recommended the first approach when I meant to say I recommended the second approach (which matched the description I then gave of what I was recommending). I'll fix that comment. I spoke with Robin and she is fine with the approach of using the NIH account names for the CDR user accounts. I'll create a table which preserves the current user names, which we'll need for any reports on comments added to CDR documents by specific users.

Just a heads-up that I'm working on this right now on the DEV server, so logging into the CDR won't always work this afternoon. :-) Will let you know when it's done.

Well, I believe the pieces are in place. However, there are still some rough edges to be worked out.

First, the instructions. You will need to open the CdrSetup9.0 folder on the bastion host's common desktop, and double-click the InstallCdrClientFiles program (even though you've done it before) so you get a new loader that knows how to log in using Windows Authentication. Now when you log in (on DEV) you enter your NIH domain account's name and password in the dialog box where you used to enter your CDR user name and password.

The rough edges have to do with browser interaction with the web server. The only browser I can get to navigate the CDR Admin pages without challenging me for my Windows credentials at least once for each page is Internet Explorer (that's the first problem). The second problem is that when you click on the XMetaL icon to take you to the admin pages, there's a long delay, though navigating from there seems to be OK.

I suspect I'm going to need some assistance from someone with more expertise with the subtleties of IIS than I have to figure out what's going on.

So, the bottom line is that DEV is usable, but not as usable as we'd like (yet).

More progress. I've modified the CDR server so that the creation and editing of users supports the two types of authentication, and made comparable changes to the cdr Python module and CGI scripts for managing user accounts. Seems to be working OK.

QA has completed and the ticket has been submitted to CBIIT for deployment to stage, after which an appscan will be requested.