How to do Form-based/username-password login (passing in request.username and request.password)?

[Legacy User]

Hi,

 

We are working with the SSG OAM custom assertion that CA has, and are trying to make a test SSG policy that does form-based authentication and that works with that OAM assertion.

 

The thing is that the way that that assertion is implemented, it expects that user credentials are in the request.username and request.password variables.

 

That works fine if HTTP BASIC authentication is being done (e.g, by using a Require BASIC authentication assertion, which populates request.username and request.password), but, the request.username and request.password are not settable (since they are built-in SSG vars) so there is direct way to do the Forms-based username-password authentication with that OAM assertion.

 

I know that there is a way to solve this, because we did this in some test SSG policies many years ago, but I cannot recall HOW?  I *seem* to recall that it was a kind of "tricky" thing to do... maybe involving something like a redirect and injecting an Authorization HTTP header, or, I vaguely remember something like using some kind of transform or something like that?

 

Does anyone know how to do that?

 

Thanks,

Jim

[Zhijun He]

Hello James,

The form-based parameters can be retrieved with ${request.http.parameter.name}, use them to compose an xml document in a context variable, and then use "Require XPath Credentials” assertion the create the credentials for authentication.

 

For example, assume that you have username and password in the post form, then

Set context variable mycredential as message: <cred> <Username>${request.http.parameter.username}</Username><Password>{request.http.parameter.password}</Password></cred>

On the "Require XPath Credentials”, right click and select the target message as mycredential(the above message)

 

I didn't test, but it should work.

 

Regards,

Mark

[Legacy User]

Hi,

What you are suggesting sounds "vaguely" familiar (i.e., I think that may've been what we had done before).  I will give it a try and see if that works and post back.

 

My brain is "foggy" (like I said, we had done something like this a number of years ago), but is there ALSO another/different way of doing something like this (Form based login) where, in one SSG policy, it does something like send/present the form login page, and then when the form data is POSTed, that that same policy takes the username and data and then does like a redirect with the Authorization HTTP header with the username and password BASE64-encoded or something like that?  I seem to recall that we had also done something like that.

 

Thanks again,

Jim

[Legacy User]

Hi Mark,

 

As a simulated test, I made a small policy where I:

 

set context var mycred (message)=<cred><Username>myuser</Username><Password>mypassword</Password></cred>

 

${mycred} Require Xpath credentials             <=== (i.e., I selected the var ${mycred} as the target message)

 

But, after the Require Xpath credentials, it still says request.username and request.password don't exist.

 

Shouldn't that have work? 

 

Jim

[Zhijun He]

Hello,

I believe you set  the wrong xpath, for the xml you used (or in my example), you don't need to change the default xpath, just use //Username, and //Password.

 

Regards,

Mark

[Legacy User]

Hi,

 

I think we (or maybe I am) are mis-communicating.

 

What I was trying to say that I did was that I did use the Require Xpath Credentials assertion, as you originally suggested.

 

However, in my case, I wanted to use a context variable, ${mycred}, as the input TO the Require Xpath assertion instead, so after adding the Require Xpath assertion to the policy, I right-clicked on the assertion to select the target, then, selected "context variable" instead of Request as the target message.

 

However when I test, by just hitting that URI with a browser, that doesn't seem to work... the Require Xpath credentials is not able to extract the request.username and request.password from the XML message that is in the ${mycred} context variable.

[Legacy User]

By the way, I should mention that if i leave the target message for the Require Xpath Credentials assertion as Request (which is the default), and if I then send a request with a body content and a POST with the XML into the SSG, that DOES work.

 

The reason I wanted to try to use a context var with the XML as the Target message for the Require Xpath Credentials assertion, is that, for some testing where the XML was hard-coded, I could then just send a GET request, rather than somehow having to send a POST in.

 

Jim

[Zhijun He]

I done a test, it's working fine, I will attach my test policy.

My lab box has user mark, so the post request body is,

username=mark&password=7layer

 

you can change to any user in your IDP

Attachment(s)

formCredential.xml.zip   1 KB 1 version

[Legacy User]

Hi,

Thanks for the test policy.

There is one (probably big) difference between your test policy and what we are doing.

In your test policy, you select the target message as the ${cred} for both the Require Match Xpath credential assertion and then subsequently for the Authenticate against identity provider assertion.

In our case, we are trying to use the SSG OAM assertion, and unfortunately, that OAM assertion does not allow us to select the target message for the OAM assertion, and I think that is why this won't work for us.

 

I have a kind of separate question:

 

In your test policy you do set the ${cred} as the target for both the Require Match Xpath assertion and for the Authenticate assertion.  That kind of seems to imply that when the Require Match Xpath assertion is executed, it is somehow modifying contents of the ${cred} context var, but I tried outputing ${cred} both before and after the Require Match Xpath, and the output looked exactly the same, so I guess I don't understand what is going on ??

 

Can you explain?

 

Thanks,

Jim

[Legacy User]

Hi,

 

I think that I literally just got it working. 

It looks like the OAM assertion implicitly expects the username and password to be in vars request.username and request.password, i.e., it behaves like target message is a var named "request" (lower-cased var name)!!

 

So, in my policy, I did the Require Match Xpath with target ${request} then just invoked the OAM assertion (which doesn't allow for an explicit target).

 

And then I tested, and it works!!

 

"It is always what you don't know, or are not told, that will kill you!"

 

Jim