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] <javascript:>
> > wrote:
>
>> check this out http://www.pac4j.org/
>>
>> On Mon, Dec 12, 2016 at 6:12 PM, Rob <[email protected] <javascript:>> 
>> 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] <javascript:>.
>>> 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] <javascript:>.
>> 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