Form Login for Windchill?

[tbusch]

Has anyone found a way to successfully implement form-based login for Windchill 9.1? What I'm looking for is to eliminate the basic login popup and send the user to a simple login form instead, similar to how most other enterprise applications work.

One thing I'm worried about is that I don't know if Pro/E's integration with Windchill depends on basic authentication.

Thanks for any advice!

-Tom

[jessh]

The Windchill server will work fine with form-based authentication.
The server really does not care how authentication is done -- just that
it knows who the authenticated user is.

Various clients will /not/ work with form-based authentication, however.

There's a fundamental issue with form-based login -- it's an application
convention that assumes either:

1. An interactive browser session with a human user or
2. All clients are specifically coded for the specifics of the
form-based authentication in question.

When a browser gets a form-based "challenge" it is clear to the human
user that they need to fill in their credentials. When other forms of
clients make an HTTP(S) request and get a 200 (OK) response containing
HTML, they don't have any clue that this is an authentication challenge
-- they assume it's the response they asked for and then utterly break.
In contrast with protocol-based authentication the application will get
a 401 response unambiguously stating that this is an authentication
challenge.

--
Jess Holle

[tbusch]

Well, on a theoretical level, you're right and it is an easy problem to solve. You simply direct systems at web services which are authenticated differently than the UI. I've solved that problem many times in home-grown applications.

My question is, however, is there support for form-based authentication specifically in Windchill and if so how is it configured? How do I tell my users "If you're having trouble logging in, remember that your username is your email address" or "If you forgot your password, please call the help desk at extension 1234" ?

Yes, I know I can just override the 401 page, but I'd like to find a way to give them reminders before they generate more traffic for our help desk! 🙂

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[ssenthil]

A quick work around could be embed your instructions/tips over the splash
image that you first come upon.



Thank you and have a great time.

Best Regards

Swamy Senthil

Principal Solutions Architect

973 216 0456(M); 973 324 2729(W); 866 908 6561(F)

Work Email: swamy.senthil@swasen.com

LinkedIn Profile:

[tbusch]

Yeah, that and the 401 page combined might be the only way to approach this! I am just hoping someone will pipe up with "We did that! Here's how!" 🙂

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[jessh]

On 10/12/2010 8:57 AM, Busch, Tom wrote:
>
> Well, on a theoretical level, you're right and it is an easy problem
> to solve. You simply direct systems at web services which are
> authenticated differently than the UI. I've solved that problem many
> times in home-grown applications.
>
Yes, one can have separate URLs for everything other than interactive
browser sessions. That then requires that one knows how one is going to
use all URLs that are generated by the system and generate different
URLs for the various cases. Currently Windchill has one set of URLs for
all uses, though. This is simpler, but does not help work around
form-based authentication's limitations.
>
> My question is, however, is there support for form-based
> authentication specifically in Windchill and if so _how is it
> configured_? How do I tell my users "If you're having trouble logging
> in, remember that your username is your email address" or "If you
> forgot your password, please call the help desk at extension 1234" ?
>
Well, one can configure form-based authentication for Windchill like one
would for anything else. There's no existing configuration file for
this or any such as this really is not supported since many Windchill
clients will not function in this configuration. One would thus have to
convert from web server basic authentication to form-based
authentication oneself in the various configuration files -- and be at
one's own risk in terms of which clients this breaks.
>
> Yes, I know I can just override the 401 page, but I'd like to find a
> way to give them reminders before they generate more traffic for our
> help desk! J
>
As others have suggested, prior to the 401 page you can override the
splash page.

--
Jess Holle

[ssenthil]

We plugged in a password remainder/reset utility for one of our customers.
Using the utility the password can be reset and emailed to the user. This
considerably reduced the calls volume to the help desk.



Thank you and have a great time.

Best Regards

Swamy Senthil

Principal Solutions Architect

973 216 0456(M); 973 324 2729(W); 866 908 6561(F)

Work Email: swamy.senthil@swasen.com

LinkedIn Profile:

[ddemay]

The key to this is session management in tomcat being able to manage user info as http RMI is used with methodserver. So a bridge needs to be built to pull the data from the http post of the forms login and insert the credentials as via http headers in a redirect.

You have to write intelligence to sniff out their credentials in http traffic and get tomcat and apache configured for this to supply a 401 response when session expires. That way, when clients that do not support form authentication use the system, they are prompted to login the normal way.

I recall you are a Michigander, yes? You going to be at SMUG? We can talk more tomorrow if so.

Dave

Sent from my Verizon Wireless BlackBerry

[tbusch]

Yup, I'm a gander! And yes, I'll be there with a few coworkers tomorrow. I'm looking forward to it!

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[imendiola]

Hi all,

a simple solution to this will be to implement a custom page in Apache for the "Login Authorization Failed" with all the info needed to solve login related issues.

Anyway, some time ago I implemented a form-based authentication system for Windchill in a development environment based in OpenSSO. It was a software developed by Sun Microsystems, and I wrote a custom login module, that was redirecting to form based authentication if the client was a browser (IE, Firefox, Chrome) and performing basic authentication in other cases. I tested it with web browsers, ProE, UG and Catia Worgrup Managers, and worked fine. However, other issues in the company where I was working with this, stopped the project, and never was implemented in a production system.

Another problem with OpenSSO is that Oracle bought Sun, and discontinued the OpenSSO project (perhaps to continue selling Oracle's SSO solution), but there is a fork of it called OpenAM that continues with the open source project.

Regards

Iker Mendiola

Prambanan IT Services
http://www.prambanan-it.com

[MartyRoss]

In Reply to Iker Mendiola:

[...] I wrote a custom login module, that was redirecting to form based authentication if the client was a browser (IE, Firefox, Chrome) and performing basic authentication in other cases [...]

I like that idea! We have a potential use for it as well - I'll try it out!

I've succeeded producing a Windchill integration to a SiteMinder-backed form-based authentication scheme used in a corporate intranet by transferring the user name into the servlet request from the SiteMinder HTTP header value (SM_USER) using a servlet filter. Turned out unfortunately that the Arbortext Editor component of the architecture won't support form-based authentication AT ALL - it only supports HTTP BASIC (not even DIGEST!) - so we had to scrap that idea and go with the common denominator of HTTP BASIC (it took quite a lot of explaining to corporate security why this enterprise tool had to pass credentials onto the wire in essentially cleartext!).

I would like for us to use form based for those user agents that will support it (such as everything but Arbortext Editor), however so - thanks for the tip!

[jessh]

On 10/13/2010 8:27 AM, Marty Ross wrote:
> In Reply to Iker Mendiola:
>
> /[...]/ I wrote a custom login module, that was redirecting to
> form based authentication if the client was a browser (IE,
> Firefox, Chrome) and performing basic authentication in other
> cases /[...]/
>
Beware that there are cases (e.g. Microsoft Excel's web query
functionality) that look exactly like IE (at least last I checked), but
don't support various IE functionalities. These functionality gaps
certainly include client-side XSL transformation, but I believe this
also includes form-based login.
>
> I like that idea! We have a potential use for it as well - I'll try
> it out!
>
> I've succeeded producing a Windchill integration to a
> SiteMinder-backed form-based authentication scheme used in a corporate
> intranet by transferring the user name into the servlet request from
> the SiteMinder HTTP header value (SM_USER) using a servlet filter.
> Turned out unfortunately that the Arbortext Editor component of the
> architecture won't support form-based authentication AT ALL - it only
> supports HTTP BASIC (not even DIGEST!) - so we had to scrap that idea
> and go with the common denominator of HTTP BASIC
>
As far as the Windchill /server /is concerned, as long as the servlet
request APIs getRemoteUser() and getUserPrincipal() return the desired
user it *should* be perfectly happy irrespective of how that is
achieved. For instance, a servlet filter can be used to
wrap/replace/override these APIs to return whatever one wants. I
believe some functionalities in some older releases wanted more, e.g. a
basic auth header, but I'd consider that a bug -- albeit one to be fixed
only in newer releases in cases.

The catch is really which clients / can deal with form-based
authentication.
>
> (it took quite a lot of explaining to corporate security why this
> enterprise tool had to pass credentials onto the wire in essentially
> cleartext!).
>
Well one should really use HTTPS if one cares about protecting
credentials in /any /case (not to mention your data...) -- as form-based
login will otherwise send the credentials in clear text anyway. If one
is already using HTTPS and concerned about someone cracking HTTPS, then
that's another matter and a /much /higher security goal.

--
Jess Holle