[infinispan-dev] SASL noanonymous policy

[Tristan Tarrant]

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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat