On Tue, Sep 2, 2014 at 3:04 PM, Sebastien <[email protected]> wrote:
> Hi Martin,
>
> > but I think the authorization part is left to the application.
> Absolutely. Actually the OAuth service is specific to the company I'm
> working for, it's just a authentication system (based on our central
> directory) and there is no data the user can choose to share or not. Roles
> are then application specific
>
> > -- store the details about the requested resource (url + post data)
> Was thinking about reusing
> org.apache.wicket.RestartResponseAtInterceptPageException.InterceptData
> (which unfortunately has package visibility)
>
We can improve this for 6.18.0.
Please file a ticket (+ PR/patch would be nice!)
>
> > -- redirect to the authentication url of the OAuth provider by passing
> the callback url
> As the authorization is part of the application, we need a slot, in the
> cycle, to set AuthenticatedWebSession#signin(true) and set application's
>
This is what I meant by "a User in the Session" - MySession#user
MySession#isSignedIn() {return user != null}
MySession#getRoles() {return user != null ? user.getRoles() : anonymous }
> role. That's why I though about an IRequestHandler's url as callback (or an
> IRequestListener url?) before redirecting to the original destination...
>
Whatever kind of endpoint you choose it has to be well protected. Because
otherwise a bad user can use it to send fake data directly to it and
authenticate as whatever (s)he wants.
>
> > the oauth provider may not call the callback url and your user may not
> return to your app
> Good point! Will take care of that...
>
> Thanks everybody for your responses. I will try manage this properly...
>
> Best regards,
> Sebastien.
>
>
>
> On Tue, Sep 2, 2014 at 12:11 PM, Martin Grigorov <[email protected]>
> wrote:
>
> > Hi Sebastien,
> >
> > The button is just a UI. But the idea is the same.
> >
> > The difference is that the OAuth provider is rather an authentication
> > service than an authorization one.
> > Usually the user of some social network doesn't want to share his details
> > with random apps (like yours and mine).
> > So when you create an application at Twitter, Facebook, ... you have to
> > specify what kind of details you want to be sent to the callback url.
> When
> > an user authenticates (s)he is asked whether (s)he is willing to share
> > these details (e.g. username, email, gender, ...). In my experience users
> > use OAuth for authentication:
> > 1) to reduce the number of accounts they have
> > 2) to reduce the information they provide to random apps
> >
> > So (usually) the OAuth provider doesn't send much info about the
> > authenticated user when calling your callback. I haven't seen anything
> like
> > roles and privileges in the OAuth responses. It could be that I don't
> have
> > enough experience with OAuth but I think the authorization part is left
> to
> > the application.
> >
> > About your use case:
> > - the user tries to load some protected resource/page
> > - the application should:
> > -- store the details about the requested resource (url + post data)
> > -- redirect to the authentication url of the OAuth provider by passing
> the
> > callback url
> > - if the user agrees to share the required data then your callback url is
> > called with the data. You should use it like normal authentication token,
> > create a User in the session, etc.
> >
> > P.S. I have used a popup window for the authentication because if the
> user
> > is not willing to share all the required info then the oauth provider may
> > not call the callback url and your user may not return to your app and
> make
> > a normal account
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> >
> > On Tue, Sep 2, 2014 at 12:46 PM, Sebastien <[email protected]> wrote:
> >
> > > Hi Martin,
> > >
> > > The question is not much about having a signin button to authenticate
> the
> > > user but more how to make it work with AuthenticatedWebApplication (or
> a
> > > custom OAuthWebApplication for instance). The final goal is to keep
> > > IRoleCheckingStrategy working
> > > ie: the user access an @AuthorizeInstantiation annotated page,
> > > #restartResponseAtSignInPage (for instance) redirect to the OAuth url,
> > the
> > > OAuth service redirect to a callback, which callback is a wicket
> > > IRequestHandler, the handler sets isSigninedIn to true, sets the roles
> > and
> > > then call #redirectToOriginalDestination.
> > >
> > > That's how I see things, but I don't see any existing wicket
> solutions...
> > > Is the usecase more clear?
> > >
> > > Thanks again,
> > > Sebastien.
> > >
> > >
> > >
> > > On Tue, Sep 2, 2014 at 9:06 AM, Martin Grigorov <[email protected]>
> > > wrote:
> > >
> > > > Hi Sebastien,
> > > >
> > > > What exactly do you need ?
> > > >
> > > > I have used https://github.com/fernandezpablo85/scribe-java to
> create
> > > > "Authenticate with Xyz" buttons for signing in (e.g. with Facebook,
> > > Twitter
> > > > and LinkedIn).
> > > >
> > > > The developer of Scribe doesn't like OAuth2 (as many other
> developers)
> > > and
> > > > at some point he stated that he will not merge any new PRs for OAuth2
> > > > impls. I don't see this statement in the README now, so he may have
> > > changed
> > > > his mind.
> > > >
> > > > Another auth client provider is https://github.com/leleuj/pac4j. I
> > don't
> > > > have experience with it but it looks like well maintained.
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > > https://twitter.com/mtgrigorov
> > > >
> > > >
> > > > On Mon, Sep 1, 2014 at 6:58 PM, Sebastien <[email protected]> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > AFAIS, there is nothing about a OAuth2 client in Wicket
> > out-of-the-box
> > > or
> > > > > through a satellite project...
> > > > >
> > > > > Does somebody knows a *simple* solution for integrating OAuth2 into
> > > > Wicket
> > > > > (like a OAuthWebApplication, or maybe a ready-to-use Filter, just
> > > giving
> > > > > Consumer Key, Consumer Secret & URLs), without using
> spring-security
> > > and
> > > > > still keeping advantage of the role-based @AuthorizeInstantiation
> > > > > annotation for instance?
> > > > >
> > > > > Thanks a lot in advance,
> > > > > Sebastien.
> > > > >
> > > >
> > >
> >
>
