[ https://issues.apache.org/jira/browse/ISIS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356177#comment-17356177 ]
ASF subversion and git services commented on ISIS-2557: ------------------------------------------------------- Commit a90ca82f36f482cc8300650e81e03b964c713b94 in isis's branch refs/heads/ISIS-2712 from Andi Huber [ https://gitbox.apache.org/repos/asf?p=isis.git;h=a90ca82 ] ISIS-2557: let AuthenticationManager.authenticate(...) manage its own transaction and interaction - let Spring handle the transactional context for this method (readonly) - when passing the auth-request to the authenticators wrap the call in an anonymous interaction - Spring's transaction aware proxies cannot include public methods with final modifier (found by experiment not by documentation) > 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)