Skip to main content
T
tbusch1-Visitor
1-Visitor
October 12, 2010
Question

Form Login for Windchill?

  • October 12, 2010
  • 11 replies
  • 3551 views

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

11 replies

Show previous replies
J
jessh12-Amethyst
12-Amethyst
October 13, 2010
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

Terms & ConditionsAccessibility statement