PeopleSoft/WebLogic proxy with Shibboleth Native SP and Apache

[Eric Goodman]

The use case I was discussing is where all traffic goes through one SP (whether on a proxy or the local web server) -- not different ports and webservers. I read the original question as "should my SP be configured to require a session for ANY PS page, or should it only protect the PS login page". That is, all traffic -- whether the SP is enforcing access controls or not -- is following the same network path and it's just the config of the SP that's being discussed.

My point was that there really isn't any functional difference for authentication purposes in those two scenarios. There are two distinct sessions (ignoring the IdP) -- the SP session and the PeopleSoft session. The critical code to protect is the sign on PeopleCode -- which actually reads the headers from the SP and generates a PS session -- and this code only executes on the PS login page. 

You should be able to leave a random non-login PS page unprotected by the SP without an issue: the user will hit the PS app, the PS app will check for an existing PS session and allow access if it finds one or challenge for a login if not. The login challenge directs you back to the login page, which invokes the SP protections. 

So injecting headers into the non-login page doesn't do you any good, because PS isn't looking at the SP headers except on the page that processes new logins. As long as the login page is protected by the SP, you should have your header injection protection for PS. The decision about protecting just the login page vs. all pages via the SP would be more about user experience issues: which process redirects for logins, do they retain the relayState that the user expects, are there differences in SP vs. PS session lengths, etc.

--- Eric

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Schwoerer, Bradley J
Sent: Wednesday, January 23, 2013 11:42 AM
To: Shib Users
Subject: Re: PeopleSoft/WebLogic proxy with Shibboleth Native SP and Apache

Re-reading the original question and the follow-up, I have a few comments.

If you do not proxy the entire PeopleSoft application through Apache and only the authentication piece, you would need a much more complicated setup.  You would need the Peoplecode to detect lack of a session and detect a secure token (custom cookie or POST/GET parameter) that can identify the authenticated person.  If the person has not authenticated, you will need to redirect them to a different port/server that does have apache/shib protecting an app that can create the secure token and send them back to the weblogic server.  Here the Peoplecode would need to handle this token to create the session.  You would have all of the issues of how to securely pass between the two servers/applications a token that can identify the person authenticated.

I would not consider this advisable, but it is technically possible to not have Apache proxying all of your weblogic traffic.


-Bradley



On 1/23/13 1:12 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 1/23/13 2:09 PM, "Marc Boorshtein" <mboorshtein at gmail.com> wrote:
>
>>While I'm not working at a university that has implemented these 
>>technologies I have implemented reverse proxies for authentication and 
>>weblogic on several occasions and I would NOT only protect the login 
>>page but the entire application.  The reason is that if you only 
>>protect the login page and not weblogic someone could spoof their 
>>login by injecting a header.  Better to use the reverse proxy to cover 
>>everything to guard against that.
>
>That won't protect you. If you're talking about the headers the SP is 
>handling, then sure, but by definition you aren't, since you're 
>assuming that one could omit the application from it. So assuming you 
>mean a custom header the application is relying on, that would be a bug 
>in the application to assume such a header were meaningful.
>
>The connector that WebLogic provides for Apache automatically proxies 
>all headers the client sends to WebLogic, so anything spoofed would get 
>there anyway.
>
>Note that you have a general point, which is that it's asking for 
>security issues to selectively do this anyway, for other reasons. But 
>this would be a more specific flaw that would bite you regardless.
>
>-- Scott
>
>
>--
>To unsubscribe from this list send an email to 
>users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net