SSO for webserver

This is a tough one. An APM session is generally maintained by a session-based browser cookie, and it is the browser's behavior to share that memory space across windows/tabs that allows a second window to proceed past the initial access policy evaluation. I have two initial thoughts:

 

 

1. Is the application's logon page something distinct (ex. /logon.aspx) that no one would need to access unless attempting to logon?

 

 

2. The SSO profile should be perpetual. It should detect any request, at any time, to the logon page and submit the credentials so that the user never sees it. Can you elaborate on how logon is performed and how the SSO is configured?

 

Hi Kevin

 

1 - the applications logon page is in fact distinct - it is implemented i ./default.htm - they do not have to access this unless to logon-attempts.

 

 

2 - the sso profile should be perpetual - ehh - now am I on a bit deep water - I expected that when the SSO profile has done its job the apm module would not be waked up again before a new fresh login - can I keep the apm module watch the session?

 

 

The SSO profile is in fact pretty simple - from the F5 logon page i fetch username and password and looks for the logon form in the response from the webserver where it uses this for the logon to the webserver (in fact - it is not a logon but username and password is used in the back-stage sql server)

 

The section in the SSO profile looks like this - more "Validforms" exist but similar:

 

 

apm sso form-basedv2 /Country_dmz/Country_Server1_sso {

 

description "SSO form for Server1"

 

forms {

 

Validform_ecom_Country {

 

attribute-value Validform

 

controls {

 

PASSWORD {

 

secure true

 

value "%{session.sso.token.last.password}"

 

}

 

UserGroupId {

 

value "%{session.sso.token.last.username}"

 

}

 

}

 

id-type name

 

request-name referer

 

request-type header

 

request-value https://ecom.corp.Country/my.policy

 

}

 

 

Just curious, but have you verified that users can access the back end logon form directly?

hi Again

 

Yes they can - when they have logged on to the F5 logon page we can either "edit" the url directly and get a new logon or launch a new page and enter the URL in a new window

 

 

best regards /ti

I suspect that there's a configuration issue with your SSO. I don't see anything specified for form detection (request-value), or logon detection (success-match-value). The SSO keys off of the form detection parameter to fill in the username and password, and uses the logon detection parameter to identify a successful logon.

hi Again

 

slowly please - pretty new to f5 & apm-sso - the logon detection succes is more or less in the blind - logon ok but nothing else. Request value - can you explain this a Little? the sso form looks for the form "validform" in the page og looks then for PASSWORD and UserGroupId. Will I need to launch a iRule each time a HTTP-event is fired and then search for the / in the header or how is this normally controlled?

 

 

best regards /ti

Here are some things you should reevaluate in your form-based SSO:

 

 

For Detection: this is the section that defines what the policy is looking for. You're currently looking for a referer header that points back to "/my.policy", which certainly *may* work, but only doing initial policy evaluation (when the redirects happen). What you probably need though is to define the object itself. You said earlier that the form was on the logon form was on the "/default.htm" page, and that this page is only accessed when a user needs to logon. I would then suggest switching from Header to URI in the Form Detection settings and use this URI. If, by chance, this page has multiple forms, you can use the Form Detection section to find the specific form.

 

 

Logon Detection: this is the section that defines what the policy looks for to indicate a good logon. You have nothing assigned here. I would recommend opening a Fiddler session and watching (connected directly to the application around the APM) what the application does AFTER a successful logon. It may either redirect to another URI or present a cookie. You can define either case in this section.

 

 

From that point on, SSO is perpetual. If the user requests (or is redirected to) the defined logon page, APM will automatically inject the credentials. Users should NEVER be able to access the application's logon form again.

 

 

 

The above heading should be Form Detection.

Hi Kevin

 

Makes sense what you here explain - I'll try to create a new site which I can "play with" and implement the changes you suggest. Can I have multiple detection statements - eg: first do a URI and after that grap the form in the page?

 

 

best regards /ti

Yes, URI and form detection are separate configuration options.