Knowledge Base

Standard/default WebVue authentication

WebVue implements its own authentication mechanisms which are not related to those offered by the Microsoft IIS. It is not necessary to use any of the integrated authentication methods that IIS supports however, you may want to consider their use for additional security or for implementing Single-Sign-On strategies

WebVue authentication takes the form of the a User (name) and Password.

Implementations of Single Sign On or integration of other 3rd party authentication providers

The only possibility that currently exists for bypassing the login dialog of WebVue is to put a façade in front of WebVue which performs the authentication to PcVue and uses the session id that is subsequently returned by PcVue for the WebVue connection. The Web Demo portal illustrates how to do that.

The façade is a Web application (most likely written in ASP.NET and residing on the IIS), which makes the connection to a 3rd party authentication provider (such as Google, Facebook, Twitter or anything else) or automatically performs Windows Authentication. As soon as this is achieved it uses impersonation to open a session to PcVue (this is done by the web services toolkit operation SessionContext.OpenCustomSession()). The session id that PcVue returns is passed as an argument into the WebVue applet.

Figure #1. Authentication web page using Windows Authentication. That means the user needs to enter his credentials on Windows startup. These credentials are automatically used when accessing the Authentication web page in the web browser. No authentication dialog here. The website connects to a database and checks which PcVue account to use for this user. Then it automatically generates a web services session and automatically redirects to the index.html of WebVue. It passes the session ID through the URI. WebVue will launch without prompting the user for authentication. Single Sign On successfully implemented.

Figure #2: Authentication web page using OAuth. This works the same as above, but the user must select the desired 3rd party authentication provider and type his access credentials accordingly before impersonation begins.

What happens if the built-in authentication mechanisms of IIS are globally enabled

It is possible, in certain environments, that the built-in authentication mechanisms of IIS are globally enabled at the level of the IIS Default Web Site or the IIS Web Server as a whole. Such authentication will interfere with the operation of WebVue. If this is the case it is important to understand how IIS authentication works and to be able to decide if it is needed or not. Information about IIS authentication can be found on Microsoft’s Developer Network website using this link:
http://msdn.microsoft.com/en-us/library/aa292114%28v=vs.71%29.aspx

1. According to investigations and tests there is no restriction regarding the authentication schemes that you can apply to the virtual directory for the WebVue application (the one pointing to the /WEB folder of your project).
   
   Note: for certain authentication schemes, such as Forms Authentication, further measures need to be applied. For example, Forms Authentication requires an ASP.NET site which acts as authentication provider. For Basic and Windows Authentication and Impersonation the specific user requires read permissions to the /WEB folder.
2. It is the same for the /classes virtual directory. This is the directory from which the index.html downloads the WebVue Java applet. As this is also a “normal” http request all authentication schemes should be able to be applied. By “normal” we mean that it is executed in the context of a user interaction and the user is consequently able to enter his credentials. The only difference is that since this request is already managed by the Java deployment toolkit the dialog looks a little different for Standard Authentication and Windows Authentication.
   
3. What is currently not supported by WebVue is using Basic Authentication or Windows Authentication for the WebPropertyServer server. In this case the logon request of WebVue will time out. The reason is that the connection to the WebPropertyServer is managed from inside the WebVue code. The way this connection is established is currently not prepared to deal with Authentication because there is no way to prompt the user for credentials or to retrieve the credentials from the authentication operation previously performed for the other two resources (except maybe for Forms Authentication).