end user credentials

I could use some advise on how to get/use end-user credentials inside of a server-side script. Is it possible to get a

System.Net.NetworkCredential object, for example, that represents the end-user instead of the system account that is running the engine?

Find more posts tagged with

BPM

Comments

Tony Wheeler

Can you describe what your end goal is? You're probably already aware that your user is available under ProcessContext.UserName but I don't think thats what you're after. In a SSO sxcenario, you ProcessContext.UserName could very well be the same as your network identity so you could create a GenericIdentity object based on that name.

Tom Waskow

It mostly comes down to using web-services to connect to other systems. We have several web-services for retrieving secure information that need to know who is calling the service to determine what to return.

These services need more than just a username. We handle authentication by attaching a System.Net.NetworkCredential object to the CookieCollection of the WebService when making a call. That way there is no possibility of impersonating a different user.

Tony Wheeler

The challenge here is that it sounds like you're trying to pass credentials End User > Web Client > Engine > Web Service. As far as I know, the engine must always run as the BPM Engine Account so Kerberos passthrough is not an option. Additionally, the engine is unaware of the current HttpContext of the Web Client so Asp.Net impersonation is out of the question.

I can think of a few hack workarounds but I think the best way to do this would be to enable Windows Auth on your webservices (using the BPM Engine account's identity for security), pass the identity of your end user in the form of an argument to whatever methods you are trying to invoke (ProcessContext.UserName) in your web services, and have your web services figure what that end user is privy to based on that ProcesContext.UserName argument. This would require some changes to your existing web services.

The hack workarounds include proxy websites, and/or modifying the Web Client to grab the end user's network identity, storing that NetworkIdentity object as a serialized string somewhere (indexed by the ProcessContext.Username), then picking it back up in the server side script, deserializing it back into the NetworkIdentity object, using the WebClient class in a server side script to then call the web service (attaching that deserilaized object to the http request). This however, would be unsupported.

I'm curious if there are better ways to do this myself.

Tom Waskow

Thanks Tony, as usual you have some good advice.

It is not always possible to modify the web-services. For example, a big one we want to hit is the Microsoft SharePoint Lists service. No chance for me to modify that :smileyhappy: . We can give a generic account the permissions it needs but that creates the problem now of making our Metastorm solutions manage user permissions instead of leaving that to SharePoint.

We will give the web-proxy and credential-caching approach a try that you suggested. Was thinking of this approach ourselves but wanted to check that there wasn't a feature of Metastorm that we were not aware of first.

Tom