Forum Discussion
Thanks for taking the time to reply.
I think I understand the conditions you outline, however can I clarify the first part of your response?
So, if an SSO profile is not assigned to a Portal resource item, which are essentialy ACLs, then a profile assigned to the Access Policy will be used. Does there need to be an SSO profile assigned to the Access Policy for SSO to work, or can you simply assign these to the resource items and leave the Access Policy SSO configuration set to none?
Apart from the single occasion when I happened apon a working config combination, I don't see the SSO agent referenced in the logs. I believe that entries were prefixed with somthing like SSO v2 (or similar). On this occasion I could see the requested paths and entries when URI's used for form detection were matched. Since making changes, I now seem unable to trigger SSO at all.
Is what I am trying to achieve possible?
- user authenticates successfully
- username & password are assigned to user SSO session vars
- user follows webtop link to resource A
- SSO profile attached to resource A detects SSO URI and using javascript inserts & posts session vars to login script
- user follows webtop link to resource B
- SSO profile attached to resource B detects different URI and posts session vars to resource B login script
Apologies for all the questions, I am new to APM and I've been at a dead-end with this for many days.
It wasn't easy and joining the dots between each component, understanding how they interact and what is going on at a low-level (especially with the SSO agent) proved challenging but I did get my solution working for most of the portal apps that I present to users.
If you simply need to send the user's credentials to a web application then a simple SSO Configurations > Forms object would probably suffice.
You would only need to use the Forms - Client Initiated object if the previous method fails to work. The reasons for this are commonly application security related - the application sets cookies and context which prevents direct authentication.
If this is the case then you need to resort to the Forms - Client Initiated method.
The first thing you need to do is increase logging. If you are using a more recent release, the logging is enabled in the General Settings of the the SSO object itself.
After you have created your SSO Configurations > Forms - Client Initiated - set the Log Level to Informational or Debug.
Now break your troubleshooting into two parts:
- detect the logon 'page'
- identify the logon form within the 'page'
You will see in the logs something like "SSOv2 MATCH" (happy to be corrected) if the login page is detected. I most commonly detect this via the URI of the HTTP stream being sent from the backend resource.
If the logon page is not detected then everything else is futile.
Once the page has been detected, identify the form. For most simple forms you can simply use the Form Paramaters to identify the form. These are defined anyway as this is where you map local APM variables to the resource's form variables. Failing that try to use a the ID element if this is unique.
Once you have successfully identified the form, the SSOv2 agent should match the login page, identify the form and using some hidden javascript sent to the client browser, autosubmit the relevant values to the backend system.
Again - if the logon form is not detected, then the SSO agent will not be triggered and nothing else will happen. Detection is where most of my problems lay. I still have one problem app that loads the authentication form client-side after the DOM has loaded and is not detectable by APM within the HTTP stream, but for the most part I have been able to detect and identify the form eventually.
One final thing to point out. APM substitutes internal tokens for SSO credentials as they are sent to the client browsers. These are then replaced with stored variables as the form passes back through BIG-IP en-route to the backend server. This ensure that the information is secure as you don't want something like a password sitting in clear-text in a web-page cache.