Forum Discussion

Seth_Cooper's avatar
Seth_Cooper
Icon for Employee rankEmployee
Nov 26, 2013

Portal Access SSO

I am working on a portal app and SSO configuration for fronting an internal web application. Here is my issue...

 

This app has one page pagename.exe and all requests are posts to this page. With SSO when I login it fires and sees the URI of pagename.exe and fires posting the USERID to the page. I then click on the next selection which posts to pagename.exe and SSO fires again posting the USERID and since that value exists it basically takes me back to the selection page.

 

The question is this... how can I add SSO for the first time we request to this page and not have it apply to the subsequent request to the same URI? Also when I want to kill the session and logout how can I accomplish this since it will still flag off the same URI? There are POST parameters passed when clicking on these links... is there a way to inspect the post parameters for this configuration instead of using just the URI?

 

Thanks in advance for the help...

 

Seth Cooper

 

APM
application delivery
devops
iRules
security
SSO

1 Reply

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Nov 27, 2013

    Challenging multi-part question.

     

    how can I add SSO for the first time we request to this page and not have it apply to the subsequent request to the same URI?

     

    I suppose this depends on how it all works, but you could potentially track access to specific URIs and issue a WEBSSO::disable command as appropriate.

     

    Also when I want to kill the session and logout how can I accomplish this since it will still flag off the same URI? There are POST parameters passed when clicking on these links... is there a way to inspect the post parameters for this configuration instead of using just the URI?

     

    You could collect the payload on each HTTP request (assuming a POST message and some specific URI) and parse out the parameters in the HTTP_REQUEST_DATA event. This all still happens before the access events, but as long as the client is also passing an APM session token, you can write into the session as needed.