Hi,
Did you ever manage to solve this? I'm also looking for a way to
authenticate/authorize base on dynamic content in the @PathParam of the
request.
Do we need to extend the AuthFilter, so that we can change the interface of
the Authenticator to include the context? Or is there a better way?
Thanks,
Dan
On Wednesday, 13 July 2016 19:50:44 UTC+1, Saumitra Bhave wrote:
>
> BTW, Just for completeness, I cannot subclass any of the DropWizard
> provided AuthFilters as all of them have private constructors only. I am
> trying all your suggestions by extending AuthFilter directly.
>
> On Thursday, July 14, 2016 at 12:06:33 AM UTC+5:30, Saumitra Bhave wrote:
>>
>> understood. but then my problem remains unsolved, let me elaborate the
>> problem again,
>>
>> Basically I want to authorize the user based on PathParams, to take this
>> decision, I need 3 things at one place 1. The Principal 2. PathParams 3.
>> Roles to check against (Provided via annotations)
>>
>> With the suggested code, I can look at the PathParams in my subclassed
>> authenticate but I neither have the Principal nor the Role to check
>> against. One solution is to put PathParams into my principal subclass, so
>> that its available to me inside authorizer.authorize, but looks kind of
>> hacky.
>>
>> On Wednesday, July 13, 2016 at 10:49:17 AM UTC+5:30, Evan Meagher wrote:
>>>
>>> AuthFilter instances are shared by all application threads within a
>>> Dropwizard server, so they need to be thread-safe. Reassigning
>>> `authenticator` within the `filter` method would risk leaking
>>> `ContainerRequestContext`s across threads handling different requests.
>>>
>>> All your AuthFilter subclass should have to do is override the
>>> `authenticate` method to inspect the request context before passing through
>>> to `super.authenticate`:
>>>
>>> public class PathInspectingBasicAuthFilter<P extends Principal>
>>> extends BasicCredentialAuthFilter<String, P> {
>>> @Override
>>> protected boolean authenticate(ContainerRequestContext
>>> requestContext, C credentials, String scheme) {
>>> // Inspect the PathParams within `requestContext` and maybe
>>> return false.
>>> ...
>>>
>>> return super.authenticate(requestContext, credentials, scheme);
>>> }
>>> }
>>>
>>> Note that I took the liberty of extending `BasicCredentialAuthFilter`,
>>> since based on your example you appear to be using basic auth.
>>>
>>> On Tue, Jul 12, 2016 at 9:22 PM, Saumitra Bhave <[email protected]>
>>> wrote:
>>>
>>>> Hi Evan:
>>>>
>>>> Thanks a lot for your help, I got the idea from your post but not sure
>>>> if I implemented it right, following is what I have done based your
>>>> suggestion.
>>>>
>>>> RequestAwareAuthFilter.java
>>>> "
>>>>
>>>>
>>>> public class RequestAwareAuthFilter<P extends Principal> extends
>>>> AuthFilter<String, P> {
>>>>
>>>> private AuthenticatorFactory<String, P> authFactory;
>>>>
>>>> private RequestAwareAuthFilter(AuthenticatorFactory<String, P>
>>>> authFactory) {
>>>> this.authFactory = authFactory;
>>>> }
>>>>
>>>> @Override
>>>> public void filter(final ContainerRequestContext requestContext) throws
>>>> IOException {
>>>> final String credentials =
>>>> getCredentials(requestContext.getHeaders().getFirst(HttpHeaders
>>>> .AUTHORIZATION));
>>>>
>>>>
>>>> authenticator = authFactory.get(requestContext);
>>>>
>>>>
>>>> if (!authenticate(requestContext, credentials,
>>>> SecurityContext.BASIC_AUTH)) {
>>>> throw new
>>>> WebApplicationException(unauthorizedHandler.buildResponse(prefix, realm));
>>>> }
>>>> }
>>>>
>>>> @Nullable
>>>> private String getCredentials(String header) { ... }
>>>>
>>>> public interface AuthenticatorFactory<C, P extends Principal> {
>>>> Authenticator<C, P> get(ContainerRequestContext requestContext);
>>>> }
>>>> }
>>>>
>>>> "
>>>> Does that make sense? Basically its very much inspired by the existing
>>>> OAuthFilter, but in this case, the builder provides a way to set
>>>> 'authenticator factory' instead of a singleton authenticator, then I
>>>> create
>>>> a new Authenticator with request context in each filter call.
>>>>
>>>> This allows me to inject the same request context into the Principal
>>>> subclass inside 'Authenticator.authenticate(credentials)'
>>>>
>>>> Is this the best way to achieve what I need? or am I over engineering
>>>> things here?
>>>>
>>>> Thanks again,
>>>> Saumitra
>>>>
>>>> On Tuesday, July 12, 2016 at 8:06:47 AM UTC+5:30, Evan Meagher wrote:
>>>>>
>>>>> Can you provide relevant snippets of your code, please? If you're
>>>>> using AuthDynamicFeature, then you're presumably still creating an
>>>>> AuthFilter to pass to its constructor. In which case you still have
>>>>> access
>>>>> to the `ContainerRequestContext` within `AuthFilter.authenticate`.
>>>>>
>>>>> If you're relying on an AuthFilterBuilder to create a filter for use
>>>>> with AuthDynamicFeature, then perhaps you can simply manually create an
>>>>> AuthFilter subclass in order to regain access to
>>>>> `ContainerRequestContext`s.
>>>>>
>>>>> On Mon, Jul 11, 2016 at 1:28 PM, Saumitra Bhave <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> I just moved from custom AuthFilter to dropwizard's authentication
>>>>>> Feature, One problem I am facing is that I can not access "PathParams"
>>>>>> in
>>>>>> the authorize method.
>>>>>>
>>>>>> Basically, my requirement is simple, in that, For Eg. User A has
>>>>>> signed in and he has access to modify user B, I have this information
>>>>>> stored in the UserPrincipal at the time of authenticate call. Now, I
>>>>>> want A
>>>>>> to be able to access PUT /users/A and PUT /users/B but not anything else.
>>>>>>
>>>>>> In the custom implementation, I used to store
>>>>>> UriInfo.getPathParameters() into the security context, and I could use
>>>>>> user
>>>>>> principal and the Path together to resolve complex Authorization queries.
>>>>>>
>>>>>> Is there anyway I can achieve the same using DropWizard's
>>>>>> AuthDynamicFeature?
>>>>>>
>>>>>> Regards,
>>>>>> Saumitra
>>>>>>
>>>>>> --
>>>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> 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.
