> I think that only ticket.getChainedAuthentications() have to be evaluated > (which include the previous two).
Chained authentications are only meaningful for proxy chains and are deliberately not checked here. (see below) > Suppose this scenario: > There are two service: SA and SB. > The user UA is allowed to the service SA but he is not allowed to the > service SB. > The user UA try to access the service SB, through a proxy ticket of the > service SA. > Before the creation of the proxy ticket, at the method > ContextualAuthenticationPolicy.isSatisfiedBy() is passed an authentication > with a principalId of this kind: "https://myhost:8443/SA/proxyCallback"; and > I cannot evaluate if the user behind this authentication is allowed to > access the service SB. Honestly, authentication policy here was only designed to perform checks on authentications that result from presentations of credentials by users (i.e. the multi-factor use case). There's simply not enough information returned from a proxy callback authentication event to do anything meaningful (at least as implemented in its default impl of a PKIX trust check on a SSL/TLS connection). I'm open to expanding the policy to include proxy use cases, but it's not at all clear how that could happen while preserving the foremost use case, namely implementing security policy around user credentials. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
