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