You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Daniel Keir Haywood (Jira)" <ji...@apache.org> on 2021/04/09 19:29:00 UTC

[jira] [Commented] (ISIS-2557) Remove secman's shiro realm and replace it with a more general purpose Authenticator

    [ 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)