Forum Discussion

mmueller78's avatar
mmueller78
Icon for Nimbostratus rankNimbostratus
Dec 23, 2016

Re-using IdP-init SSO links with different credentials in a single browser session

I am setting up an SAML SSO with F5 APM as IdP for what appears to be an unusual use case. I have been reading various DevCentral articles related to this and just cannot seem to figure it out.

 

The use case is as follows:

 

Page on the company intranet site will provide links to two urls for IdP-initiated SSO.

 

Link1 is for local AD users who have registered their account with SP's site and once they click URL, are prompted to supply AD credentials, and upon successful auth/SSO, are redirected to SP's site logged in as themselves and shown content they have customized. URL is something like https://ssovirtual.mycompany.com/idp_ad_user.

 

Link2 is for users who have not registered with the SP and who will not be required to provide credentials (no logon page), and thusly logged on with a "service account" in local AD that corresponds to a generic user at SP and upon clicking the link, SSO occurs and redirects them to a similar page at SP that shows generic content. The service account is assigned via Variable Assign module. Link2's URL is https://ssovirtual.mycompany.com/idp_sa_user.

 

I have accomplished the above with a single virtual server with an access policy applied, as well as an iRule that uses an ACCESS_POLICY_COMPLETED event with ACCESS::respond 302s to the SAML resource URL of each IdP logon scenario based on the landing uri. We do not want to expose a Webtop to the users.

 

Furthermore, the end users need to be able to re-use the links within a single browsing session, without APM session errors and without closing browser, clearing cache, etc. So the users will browse to the intranet page, click the IdP-init link appropriate for their usage, browse the SP site as their user or the generic user, and either close that tab or otherwise browse to someplace else on the web. At any point in the same browser session, they will re-visit the intranet page again and click either of the IdP-init URLs and re-SSO to the SP site.

 

I should mention at this point that I am catering to users of IE, which is the default browser on the machines of the end users.

 

I can get around the APM session errors that re-using the same link (as previously used) causes by adding a HTTP_REQUEST event to my iRule, and doing a HTTP::redirect or HTTP::respond 302 to the SAML resource based again on URL path.

 

Ideally, the users could also switch between using the two different links/URLs, such that a AD link user is sometimes a service account user, and vice versa, without APM errors. The closest I have been able to get is a user who successfully SSO-es with their AD creds, when browsing away from the SP site and back to the intranet site to click the service account link, will be SSO-ed back into the SP site as their AD user account and not the generic Service account.

 

The browser does not seem to be respecting my attempts to set cookie expiration at the time of the redirect/respond, and anywhere I seem to put a ACCESS::session remove, I cannot SSO to the SP site with policy deny result, and using HTTP::cookie remove, such as for MRHSession or LastMRH_Session cookies, I get mixed results of policy deny, APM session errors, etc.

 

Is what I am doing possible? Any insight on what to try? Thanks in advance.

 

APM
application delivery
iRules

1 Reply

Sort By
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Dec 27, 2016

    Your custom scenario and ones like it is basically the reason that BIG-IP has irules and APM has a logic flow.

     

    Some tips that may be helpful:

     

    Don't use ACCESS::session remove. It is almost never appropriate because it only ends the session on the APM server and not on the client. If you want to end the session, redirect the user to APM's hangup page (/vdesk/hangup.php3). That will destroy the cookies, end the APM session, and put the user into a landing page that indicates logout.

     

    If you want to modify an HTTP response to the client, use HTTP_RESPONSE_RELEASE. This event happens immediately before it's transmitted so you can modify anything, including APM-insered stuff.

     

    Some of the HTTP connections occur between the client and APM itself to get APM resoruces so the "HTTP_REQUEST" event happens at a strange time because the request is internally handled instead of going out to an external server.

     

    Normally APM will use the session variable "session.server.landinguri" to redirect the user once the access policy is complete. This session variable can be used during access policy evaluation also so that you can tell what the user FIRST navigated to when creating the session. It can be useful in a lot of cases where you want to make logic based on the beginning request.