[CAUSEWAY-2557] Provide a more general purpose Authenticator as an alternative to having to route through Shiro.

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0.0-M5
• Fix Version/s: 2.0.0-M6
• Assignee: Daniel Keir Haywood
• Reporter: Daniel Keir Haywood
• Created: 02/Mar/21 07:21
• Updated: 25/Jan/23 10:34
• Resolved: 01/Jun/21 05:51

Description

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.
 
 

Issue Links

• relates to: CAUSEWAY-2534 Spring Security Integration
• links to: GitHub Pull Request #571