On Oct 22, 4:12 pm, Daniel Borlean
<DanielBorl... RemoveThis @discussions.microsoft.com> wrote:
> Thanks for the info. Actually, after much trial and error, I discovered the
> solution:
>
> Use the ISAPI_Rewrite filter with the following httpd.conf configuration:
> RewriteEngine on
> RewriteCond %{REMOTE_USER} TEST\\(.*)
> RewriteHeader SSO_USER: .* %1
>
> This ISAPI filter parses out the userid from the REMOTE_USER server variable
> (after the "TEST\" domain portion) and adds the custom SSO_USER HTTP header
> to the request to the Java webapp that now knows who the authenticated user
> is. This, I'm assuming, only works with Integrated Windows Authentication.
Your solution works with any standard Authentication protocol
supported by IIS which populates those server variables.
For your situation, Windows Authentication will populate REMOTE_USER
with the Windows username, which you then remap with the ISAPI Filter
to SSO_USER: request header and have that resulting request be proxied
by isapi_redirect.dll to Java.
For Windows Authentication, you will find LOGON_USER more
representative of the actual user that IIS logged on to execute the
request (which is what gets proxied by isapi_redirect.dll).
REMOTE_USER and AUTH_USER are parsed from the HTTP request header and
does not account for ISAPI Filter CustomAuth modifications.
FYI: your scheme works... but is actually very insecure, but that is
the nature of patch-work SSO solutions that cross multiple
authentication protocols. Secure SSO solutions would never allow an
ISAPI Filter to do the man-in-the-middle attack that forms the basis
of your solution.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
>> Stay informed about: Can IIS perform SSO for Java webapp?