Forum Discussion
Single sign-on to my IIS Web service
I forgot to ask. Is the client able to consume and relay HTTP cookies? The following is a very crude first stab at this:
when HTTP_REQUEST {
HTTP::header insert "clientless-mode" 1
}
when ACCESS_SESSION_STARTED {
if { [HTTP::uri] starts_with "/api/Authentication/Login.php?" } {
set username [URI::query [HTTP::uri] username]
set password [URI::query [HTTP::uri] password]
ACCESS::session data set session.logon.last.username $username
ACCESS::session data set session.logon.last.password $password
}
}
when ACCESS_ACL_ALLOWED {
HTTP::header replace UPN [ACCESS::session data get session.ldap.last.attr.userPrincipalName]
}
The idea is this:
-
The clientless-mode header is inserted within an HTTP_REQUEST event to tell APM to not throw the initial redirect to /my.policy. This is usually an important requirement for non-browser clients.
-
Assuming the very first request to the APM VIP is the login URI, we'll grab the username and password in the ACCESS_SESSION_STARTED event and assign those to session variables.
-
With clientless-mode enabled, your visual policy must be "headless", meaning no logon pages, message boxes, or anything that is browser-dependent. At this point we have the two session variables that be plugged directly into an authentication agent (AD/LDAP auth, RSA, etc.).
-
If all is good, data flow passes to the allow branch in the policy. For demonstration purposes I added an ACCESS_ACL_ALLOWED event that sends an HTTP header to the server in every request, in this case the result of an LDAP query. In your case, you may not need this and simply fail if RSA auth fails.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
