[infinispan-dev] SASL noanonymous policy

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] SASL noanonymous policy

Vojtech Juranek
Hi,
the behaviour of HR authentication handler has changed recently [1]. Now, if
HR authentication is enabled, anonymous access over HR is disabled unless SASL
property NOANONYMOUS is set to false. While I agree that disabling anonymous
access by default is reasonable, on the other hand I find this approach
confusing for 2 reasons:

* my understanding of ISPN security mode was that "what is not explicitly
forbidden it's allowed" (this is itself IMHO quite confusing, but OK) - e.g.
if the security is defined on cache container level, access to all caches is
granted to anyone, unless security is defined also for given cache. Recent
change takes different approach "what is not explicitly allowed is forbidden",
IMHO making whole security configuration even more confusing for the users.

* SASL policy is actually intended for SASL mechanism negotiation (see e.g.
"How SASL Mechanisms are Installed and Selected" in [2]) so that it doesn't
have to be specified explicitly and shouldn't be used in server logic. Using
it in sever logic can be again quite confusing for users and, even worse, can
result into security flaws - e.g. admin which expects that EXTERNAL
authentication will be used will set SASL policy to NOANONYMOUS and the side
effect would be that any unsecured cache can be access by any (non
authenticated!) user.

IMHO HR authentication handler should be rewritten so that is just passes SASL
policy to SASL server and don't use it in sever logic and we also should sick
with one approach "what is not allowed is forbidden" or "what is not forbidden
is allowed" and we should use it consistently everywhere where security comes
into the play.

Thoughts?

Thanks
Vojta

[1] https://github.com/infinispan/infinispan/commit/
edaf39bd09a52a37f28abe9fdc29ee3214d6c256
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] SASL noanonymous policy

Tristan Tarrant-2


On 01/03/17 10:15, Vojtech Juranek wrote:
> Hi,
> the behaviour of HR authentication handler has changed recently [1]. Now, if
> HR authentication is enabled, anonymous access over HR is disabled unless SASL
> property NOANONYMOUS is set to false. While I agree that disabling anonymous
> access by default is reasonable, on the other hand I find this approach
> confusing for 2 reasons:
>
> * my understanding of ISPN security mode was that "what is not explicitly
> forbidden it's allowed" (this is itself IMHO quite confusing, but OK)

I think that we need to make a clear distinction about authentication
and authorization.
While your statement is true for authorization, it should never have
been so for authentication. Also, authentication should never depend on
authorization being set up, as enabling authorization has quite an
impact on performance (the opposite, i.e. authorization requiring
authentication, is however true).
If a user enables authentication on the endpoint, the expected behaviour
should be that non-authenticated clients will fail to connect.

Tristan

- e.g.

> if the security is defined on cache container level, access to all caches is
> granted to anyone, unless security is defined also for given cache. Recent
> change takes different approach "what is not explicitly allowed is forbidden",
> IMHO making whole security configuration even more confusing for the users.
>
> * SASL policy is actually intended for SASL mechanism negotiation (see e.g.
> "How SASL Mechanisms are Installed and Selected" in [2]) so that it doesn't
> have to be specified explicitly and shouldn't be used in server logic. Using
> it in sever logic can be again quite confusing for users and, even worse, can
> result into security flaws - e.g. admin which expects that EXTERNAL
> authentication will be used will set SASL policy to NOANONYMOUS and the side
> effect would be that any unsecured cache can be access by any (non
> authenticated!) user.
>
> IMHO HR authentication handler should be rewritten so that is just passes SASL
> policy to SASL server and don't use it in sever logic and we also should sick
> with one approach "what is not allowed is forbidden" or "what is not forbidden
> is allowed" and we should use it consistently everywhere where security comes
> into the play.
>
> Thoughts?
>
> Thanks
> Vojta
>
> [1] https://github.com/infinispan/infinispan/commit/
> edaf39bd09a52a37f28abe9fdc29ee3214d6c256
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] SASL noanonymous policy

Vojtech Juranek
On středa 1. března 2017 10:56:08 CET Tristan Tarrant wrote:
> I think that we need to make a clear distinction about authentication
> and authorization.

ok, I mixed these two together when I was thinking about it, you are right.
Thanks for reminder

vojta

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

signature.asc (484 bytes) Download Attachment