[
https://issues.apache.org/jira/browse/ISIS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318223#comment-17318223
]
Daniel Keir Haywood commented on ISIS-2557:
-------------------------------------------
Should Secman have an Authenticator at all ? I'm thinking of it more as just
an implementation of Authorizor.
One reason is that spring-security implementation (IsisModuleSecuritySpring) is
an Authenticator only ... so it suggests we keep these separate.
One area that's not yet clear to me is whether they integrate at the notion of
user (so the authorizor maps users to roles and then roles to permissions), or
if they integrate at the notion of users/roles (so that the authorizor just
maps roles to permissions). I suspect that the latter is "more correct" - I
know that authentication solutions have the concept of "claims", which are
basically roles so far as I can see.
That said, I think it can be up to the Authorizor implementation whether it
chooses to look at/honour any associated roles/claims attached to the user's
identity, or whether it only looks at the user's identity and maps that onto
roles itself.
> Remove secman's shiro realm and replace it with a more general purpose
> Authenticator
> ------------------------------------------------------------------------------------
>
> Key: ISIS-2557
> URL: https://issues.apache.org/jira/browse/ISIS-2557
> Project: Isis
> Issue Type: Improvement
> Components: Isis Extensions
> Affects Versions: 2.0.0-M5
> Reporter: Daniel Keir Haywood
> Priority: Minor
> Fix For: 2.0.0-M6
>
>
> HMM... one caveat. to the stuff below - AuthentiationManager applies an OR
> logic to all Authenticators, so only one needs to recognise the request,
> whereas we probably want an AND logic for the secman Authenticator (in
> addition to whatever the primary authenticator is). I suppose the workaround
> is to write a custom Authenticator that would be configured first and apply
> AND semantics, but that is hacky.
> ~~~~~~~~~
> Shiro can have multiple realms that contribute to the principal/subject
> representing the end user
>
> So the secman realm is (a) authenticating that the user exists in the
> database and (b) gathering up the permissions of that user in some form so
> that shiro's authorizor can determine if the user has access to a feature.
>
> We can break out these two responsibilities, though
>
> First, for authentication - making sure that a user exists in the secman
> database - we could provide an implementation of Isis' own Authenticator (eg
> AuthenticatorSecMan) that just queries the ApplicationUserRepository.
> (That's because the AuthenticationManager class asks all known Authenticators
> if an authentication request is valid.)
>
> Second, for authorisation - well, Andi wrote that already, I think.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
