I think you should look a bit more :) There is many "identity provider" 
available, depending on what you want to do, see the authentication 
mechanisms at http://www.pac4j.org/1.9.x/docs/index.html (so yes, it 
supports db-based authenticator, fb, oauth, saml, and stuffs like this). 
For your need around stateless sessions, I'm not exactly sure (but would be 
interested on feedbacks, in my own app I would like to go toward that).

It is quite simple to use, but you really need to understand the basic 
concepts of it, once it's done, it's easy :)
It should be ok for you since you already are familiar with a decomposition 
in indirect versus direct clients, exactly as implemented in pac4j 
(actually, when I read your original question, I was wondering if you were 
not a pac4j fan coming to make advertisement for it :P just kidding :).

By the way, I'm the maintainer (and user) of dropwizard-pac4j and 
jax-rs-pac4j (integrations on pac4j into dropwizard and any jax-rs 
runtime), so don't hesitate to ask questions here or on pac4j-users about 
integration in dropwizard :)

Le mardi 13 décembre 2016 17:41:36 UTC+1, Rob a écrit :
>
> I took a look at pac4j, but unless I'm missing something it seems like 
> there is no local/database identity provider?
>
> At first glance pac4j covers a lot of use cases, but that seems to come at 
> the expense of developer experience (i.e. its complex) -- but I'd love to 
> hear otherwise from those who are using it. I feel a modern security 
> framework should let you get up and running quickly with a minimum of 
> external dependencies.
>
> What about Apache Oltu - has anyone had a good experience with using that?
>
> To throw in my 2c worth, I used Apache Shiro on my last Dropwizard 
> project. Briefly:
>
> Pros:
> - Simple, easy to understand - a breath of fresh air compared to something 
> like Spring Security.
> - Minimal dependencies
>
> Cons:
> - Uses Jetty servlet filters, and every now and then you get 
> non-deterministic errors where POSTs mysteriously fail somewhere deep in 
> the call stack; this makes me afraid of using it long-term.
> - Releases have slowed down a lot; starting to feel its age; this is a 
> Java 6, 2010 era project.
> - Doesn't support OpenID/OAuth2
> - Minor: old school stateful sessions only
> - Minor: doesn't seem widely used these days, so little traffic on the 
> mailing list, few examples, etc. 
>
>
>
> On Monday, December 12, 2016 at 4:35:16 PM UTC-7, Evan Meagher wrote:
>>
>> +1 to pac4j, and specifically dropwizard-pac4j 
>> <https://github.com/pac4j/dropwizard-pac4j>. It should be able to do 
>> whatever you want.
>>
>> On Mon, Dec 12, 2016 at 3:26 PM, Shan Syed <[email protected]> wrote:
>>
>>> check this out http://www.pac4j.org/
>>>
>>> On Mon, Dec 12, 2016 at 6:12 PM, Rob <[email protected]> wrote:
>>>
>>>> I am taking a fresh look at how to best handle authorization and 
>>>> authentication in Dropwizard today. I think it would be a very helpful 
>>>> conversation for all of us if we could share what we're using for authn 
>>>> and 
>>>> authz, and what we feel would be the simplest/best/etc approach today.
>>>>
>>>> Here's my personal take on the requirements are for a modern authn and 
>>>> authz solution:
>>>>
>>>> 1) As few external dependencies as possible -  e.g. no dependency on 
>>>> external service, such as KeyCloak, Auth0, etc. Should be able to use the 
>>>> app's database as the identity provider for users and role/permissions.
>>>>
>>>> 2) Simplicity - many security libraries try to handle every protocol or 
>>>> standard, and end up being hard to configure and troubleshoot.
>>>>
>>>> 3) Works cleanly with both indirect clients (views; web form-based 
>>>> login) and direct clients (APIs). Example use case: a view rendered 
>>>> server-side has some JS that fetches data from a resource.
>>>>
>>>> 4) Simple role and/or permission based access control.
>>>>
>>>> 5) User can optionally authenticate via Facebook, Google, etc.
>>>>
>>>> 6) If an account needs to be de-activated, user can be logged out 
>>>> across all devices/sessions within minutes. 
>>>>
>>>> 7) The project is actively maintained and updated.
>>>>
>>>> Bonus: in theory stateless sessions would be nice option to have - 
>>>> although there are probably too many drawbacks to make the complexity 
>>>> worth 
>>>> it  (e.g. JWT with short-lived access tokens and long-lived refresh 
>>>> tokens).
>>>>
>>>> I don't think there's any Java solution out there that meets the 
>>>> requirements above, but I'd love to hear if anyone has gotten close.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "dropwizard-user" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "dropwizard-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Evan Meagher
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to