[ https://issues.apache.org/jira/browse/ISIS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Keir Haywood resolved ISIS-2557. --------------------------------------- Resolution: Fixed > Provide a more general purpose Authenticator as an alternative to having to > route through Shiro. > ------------------------------------------------------------------------------------------------ > > 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 > Assignee: 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)