SSO with Basic Auth question

[kenlars_]

You know what the username is - that is what the user enters when they log on. What it seems you are trying to find out is what is the name of the parameter which holds this value. You really want to do the policy trace.

[cryptochrome_]

Yes. But I think I didn't put it right. Sorry for my english. I was trying the trace and the simulation, but the username that the user enters is NOT working for the trace. In order to start a trace, I have to provide the username of the user I want to trace. After entering that username and the trace or simulation begins, that particular username is not recognized. The usernames are coming from an LDAP server so my question was whether I need to enter something else in the username field of the trace page.

[kenlars_]

OK - then what shows up for the user name in the user access log?

[cryptochrome_]

Forget it I just got the trace.

The trace looks good to me, although I am not experienced in interpreting the results. I seem to be using the right username variable. The trace lists about 10 or so different variables that I could use that all aply to the username:

2008/08/21 15:13:59 - Variable user = "xxx"
2008/08/21 15:13:59 - Variable userName = "xxx"
2008/08/21 15:13:59 - Variable realm = "xxx"
2008/08/21 15:13:59 - Variable userAttr.cn = "XXX"
2008/08/21 15:13:59 - Variable userAttr.uid = "XXX"

I tried the <USER>.suffix as well as the <USERNAME>.suffix in the ressource without success.

The trace seems to apply the correct policy though, so I assume it is sending out something to the webserver. I don't see any response from the server in the trace though:

2008/08/21 15:14:02 - Start Policy [WEBURL/SSO_BASICNTLM] evaluation for resource http:/xxx:80/netstorage
2008/08/21 15:14:02 - Applying Policy [Netzlaufwerke]...
2008/08/21 15:14:02 - Action [BasicSpecifiedCred] is returned
2008/08/21 15:14:02 - Policy [Netzlaufwerke] applies to resource
2008/08/21 15:14:02 - Start Policy [WEBURL/SSO_BASICNTLM] evaluation for resource http://xxx:80/netstorage
2008/08/21 15:14:02 - Applying Policy [Netzlaufwerke]...
2008/08/21 15:14:02 - Action [BasicSpecifiedCred] is returned
2008/08/21 15:14:02 - Policy [Netzlaufwerke] applies to resource
2008/08/21 15:14:02 - Start Policy [WEBURL/SSO_BASICNTLM] evaluation for resource http://xxx:80/netstorage
2008/08/21 15:14:02 - Applying Policy [Netzlaufwerke]...
2008/08/21 15:14:02 - Action [BasicSpecifiedCred] is returned
2008/08/21 15:14:02 - Policy [Netzlaufwerke] applies to resource

(etc....)

Any thoughts?

[kenlars_]

FYI - The fields starting with "userAttr" are the fields returned from the LDAP server.

Here is what I would do to experiment. In the USERNAME field under "Use Specified Credentials for SSO...", enter the username just as you think it should be. So, if the username is "xxx" and the suffix is "@yyy" put [email protected] in that field. Then see if the authentication works. If it does, then you can be sure the problem is with the substitution. If not, the problem lies somewhere else.

[cryptochrome_]

ok, but the ressource is for many users, so I can only do this for testing. I will try. thanks!

[imtravis_]

I think kenlars only wanted you to do it to test to see if the information that you are passing on to the SSO is correct. Once it's known to be correct, then we all can try and help with the variable.

[cryptochrome_]

Ok. So I tried entering the exact username without any variables, exactly the way it should be entered on the web application. The password was still set to variable password <PASSWORD>.

That didn't help either. No success.

Unfortunately I don't have access to the webserver logs...

[kenlars_]

I know this is painful, but just one more step, and I think you'll have convinced yourself that it is not the SA. Can you replace the "<PASSWORD>" field with the real password for the user?

[cryptochrome_]

Ok. I tried with entering a fixed username AND password. It still doesn't work. So I had the customer send me the webserver logfiles (apache with tomcat) and I found this entry:

client used wrong authentication schemeÓ

According to the customer, the server should be using BASIC AUTH.

Any more hints?