|Re: [jetty-users] 3'rd party Autentication
Maybe the solution based on a dedicated authentication server (Identity Provider based on WS-Federation) might give you some more insights how to do that. As already mentioned, the authentication server should not require the browser user to click in a return link. The WS-Federation standard describes for instance how to do that.
Here the architecture overview:
and the implementation for Jetty:
From: jetty-users-bounces@xxxxxxxxxxx [jetty-users-bounces@xxxxxxxxxxx] on behalf of larry mccay [larry.mccay@xxxxxxxxx]
Sent: 16 December 2013 16:52
To: JETTY user mailing list
Subject: Re: [jetty-users] 3'rd party Autentication
Your 3rd party authentication provider should have a prescribed way of doing this already.
In fact, you shouldn't really have to require the user to click on a link to go back.
At any rate, you need to be extremely careful about blindly accepting url parameters of an incoming request.
You will need to ensure that the request is indeed coming from your 3rd party authentication provider and not some arbitrary client that just sets the magic parameters - like you could easily do from a browser or curl.
If you can be sure (and programmatically verify) that the request has come from a trusted client then you can create a servlet filter or JASPIC authmodule to consume the parameters, create a Subject with the appropriate principals and assert the identity with a Subject.doAs.
The JASPIC authmodule is the EE recommended approach to doing this because you just communicate the primary principal and any group principals back to the container and it does the identity assertion.
On Fri, Dec 13, 2013 at 9:11 AM, Kjell Tillstrand <kjell@xxxxxxxxxxxxxxxxxxxxx> wrote:
Back to the top