How do I set an authorization filter?

[Rafael FNX]

I am using Smallrye in my application and have implemented a Blacklist system, to invalidate the token once my user logs out.

But now I need to write logic that checks if the token is not blacklisted, how can I create a filter that Smallrye would call every token authentication to check if it's valid or not?

Thanks in advance!

[Rafael FNX]

Forgot to mention that I'm using Smallrye JWT.

[Sergey Beryozkin]

Hi

If you use JAX-RS then a custom ContainerRequestFilter would do - otherwise a container specific mechanism can be applied, ServletFilter or Vert.x filter etc

Does it help ?

Thanks, Sergey

--
You received this message because you are subscribed to the Google Groups "SmallRye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smallrye+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/172e200b-9c4b-405b-8bac-c3db4f4c26a2n%40googlegroups.com.

[Rafael FNX]

Hello Sergey! Thanks for the sugestion.

I'm using JAX-RS, but I didn't want to create another global ContainerRequestFilter, that will check all route calls, including unsecured (public) ones, also because from what I saw in smallrye-jwt/implementation/jwt-jaxrs, Smallrye itself is already defining a series of global filters, so I don't think I need to create a new global filter when I could take advantage of the existing ones.

I also don't want to use @NameBinding to link a filter, as I'm already using annotations like @RolesAllowed or @Authenticated (from Quarkus), then it would be polluted, and make sure all the protected routes have a new annotation, it seems like a headache, if I forgot one, it would be possible to access it with a blacklisted token even after the user has logged out.

Checking if the token is blacklisted, to me, looks a lot like a behavior that should be in Smallrye's verification flux, so is it possible to add custom behavior to that flux?

[Sergey Beryozkin]

Hi Rafael

Jose4j provides Validator interfaces which can be used to customize the token validation - but the custom ones can not be registered at the moment,

please create an enhancement request if it is something that can be of interest.

Custom Quarkus SecurityIdentityAugmentor can also access a SecurityIdentity with a parsed JsonWebToken (SecurityIdentity.getPrincipal)

Thanks Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/9cbba6db-cc06-4c17-828e-3613f3b359e3n%40googlegroups.com.

[Rafael FNX]

Hi Sergey!

Thanks, I will consider and research Jose4j.

And thank you very much for the tip from Quarkus SecurityIdentityAugmentor, I'm trying to analyze all the possibilities to choose the best one.

And speaking of possibilities, I wanted to ask you what you think of a Custom Factory, I could create a class that extends JWTCallerPrincipalFactory, which according to the official repository notes, that you can find here, "parses and verifies" the token, my class would check if it is not on the blacklist and then delegate the rest of the process to JWTCallerPrincipalFactory, which would do the other analysis and verification.

Do you think it would be a good solution or would it be a workaround?

[Sergey Beryozkin]

Hi Rafael

Sorry for a delay - I keep switching between multiple accounts,

`CustomFactory` should be fine - but there you will see a non-parsed token.

If your system uses the encoded token as a key then it would be quite effective as it will avoid parsing the token - but it can not see Quarkus related contexts in case you need them.

In this case I'd also consider using a global filter - Quarkus authentication mechanisms are global themselves

Thanks, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/2230b54b-7ef0-4a7c-b935-ae31e64d6cf1n%40googlegroups.com.

[Rafael FNX]

Hello Sergey!

No problem, it took me a long time too.

Right, a custom factory receives an unparsed token, but delegates the work to the real factory, the real factory analyzes and validates, turning it into a JWTCallerPrincipal object, which contains the parsed token, instead of simply returning this object, I do my logic with it, and then I'll come back if it's not blacklisted.

But yes, I will use the encoded token as the key, I only commented if I was going to extract something like the "jti" field.

About Quarkus contexts, I think I would be lost then hahaha, but, if in the future I need Quarkus contexts then I will use your other tip from Quarkus SecurityIdentityArgumentor, which I think is described and exemplified here: https://quarkus.io/guides/security-customization#httpauthenticationmechanism-customization, right? 

Well, you already answered my question if I could use custom factory by saying that it will be fine.

Thank you so much for everything Sergey, without you I would still be lost in what I could or could not do.

I don't know where you're from, but here in Brazil it's Thursday, you'll probably read this tomorrow, so a great Friday for you and have a nice weekend.

[Sergey Beryozkin]

Hi Rafael

No problems at all, I don't think I've helped much, you've discovered all by yourself :-)

Enjoy the weekend

Cheers, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/ad11b256-c2b1-4437-b977-3dc1ce0251a2n%40googlegroups.com.