Authentification on a webserver on VMS from Windows

[Kirsten Knüttel]

Hello,

I think it's a bit difficult to describe, but I will do my very best.

We have a Webserver on Openvms. At the moment, when you want to open a protected web site you are asked for your username and your password. The username is established under VMS so that you have got your Windows user and password and a vms user and password. For this we must register the user in the protection file from the webserver.
Is it possible, that it is performed similar to the proxies under OpenVMS, so that you are logged in to Windows and if you want to reach a protected web site, vms compares the Windows user with the vms user in the background, and you are no longer asked for username and password again?

At the moment, we have openvms 7.3-1 and we use the OSU webserver. But if somebody can say, that this can be done by another webserver, I'm interested in it, too.

Regards,

Kirsten

[David Jones_21]

In general, all the web server knows about the connection is the client's TCPIP address and port number and mapping that reliably and securely to a username is very difficult.

Usually people kludge something up using cookies stored by the browser. The OSU server doesn't have built-in support for cookies the way Apache does.

Another approach would be to use SSL client certificates.

[Peter Quodling]

What version of OSU?

Dangerous area, you want a windows signon, and a VMS Signon to be synchronized? and serve a web access. Is this a once only signon, i.e. keep later access via cookies or the like.? Is it open internet access (are you worried about plaintext passwords being transmitted?

More details please..

Peter Q

[Antoniov.]

Hi Kirsten,
I'm afraid you can trust windows authentication by web server. TCP/IP standard, simply, doesn't carry username and password so you gave to build a your own application.
The most common way is cockie with follow limitations:
- User have to logon at first time
- User can disable cookie on his browser

Teorically you could send username (but not the password) if you write a java applet on client side that send username on server side.

Antonio Vigliotti

[Willem Grooters · Accepted solution]

Just deducting from what I know of VMS and the HTTP protocol, and what I have experienced in this area (mainly by using Apache, but I know a little about OSU):

What you want to achieve is authentication by the web browser, to check wether the requestor (HTTP bowser) ahs access to the requested page (HTTP server). Since the LOCATION where the requested page resides is protected this way, the credentials will have to be checked BEFORE the reqeust is serviced at all. Since there is, AFAIK, no automated authentication in the HTTP protocol, the only way for the server to get this data is by asking the requestor.

You can always check this in the access logs. Only if credentials have been asked, the username will show up. Otherwise, requests will be "anonymous" - without a name. So proxies have no meaning here (I think). Apache will quite likely bypass them anyway: it checks validity against SYSUAF.

However: do you need this?
If ANY user that has successfully logged in into the Windows domain has access to these protected websites, I don't see the need for an extra authentication - they already did.
The case is different if there are distictions: some are allowed acecss where others are not. As said above, the default access is "anonymous" so there is no other way to get the user's credentials that just asking. Unless there have been taken measures to make this information persistent (via cookies, indeed) this will be done each new session.
Another approach is using certificates: be your own Certificate Autority and issue certificates to those that need access to the secured site. I know it can be done using Apache, it might very well be possible to do this with OSU.

Willem
Willem

[Peter Quodling]

Can't get to the OSU Server that I look after right at the moment, but I do reacall that it (OSU) supports SSL.

[Antoniov.]

Peter,
SSL doesn't solve. The real trouble is not the safe transport of username and password (this may be a second trouble) but trusting from windows domain to web server.
At now, trusting may be implemented across network but not into web server.

Antonio Vigliotti

[Kirsten Knüttel]

Hello,

Thank you for your informations. These are the things I've thought, too. But I want to be sure, that I'm right.

the questions is related with our intranet, so no external user can see these pages. But in this intranet there are some sites only some of the users should see. Normally, you don't need a username and a password, only for these sites. Our costumer asks now, why they always must type their username and their password again, why isn't it enough, if you type it once when you logg in to windows.

By the way, the OSU version is at the moment 3.9A (I know, that this is an older version with some bugs, but I don't have the O.K. at the moment for an upgrade :-(

So, for a summary I would say, that it is the best way, we have it at the moment.

regards,

Kirsten

[Antoniov.]

the questions is related with our intranet, so no external user can see these pages.

This is not important; HTTP standard doesn't make difference between internal and external users.

However, reading carefully your last post I understand:
1) You need to hide some pages to some users.
2) You don't need really of password, you need merely the username.

On web there is some utility about this feature. For example (GPL license):
http://www.cr0.net:8040/misc/cachedump.html
here there is an exaple in java/javascript
http://www.rgagnon.com/javadetails/java-0441.html

Not sure can help you but they can give you some idea about this feature.

Antonio Vigliotti

[David Jones_21]

SSL doesn't solve. The real trouble is not the safe transport of username and password (this may be a second trouble) but trusting from windows domain to web server.
At now, trusting may be implemented across network but not into web server

Client certificates can be a solution provided the browser properly authenticates the user (e.g. cert. file password protected) prior to including it in the request. Hooks for doing access control based on client certificates were added in version 3.10a of the OSU server, see attachment.

[W. van den Barselaar]

I think mod_ntlm (http://modntlm.sourceforge.net/) can do what you want.

quote from the site: "NTLM is an authentication protocol used by Microsoft Internet Informations Server(tm) and Microsoft Internet Explorer(tm). While it is not really secure, it offers background authentication (the workstation logon credentials of users are passed through to the web server). This feature is widely used in intranets based on these Microsoft products."

You still need to maintain a list of users that are allowed to access the website, but these users no longer need to type a username / password anymore.

According to the project page it still needs to be ported to vms though.