[
https://issues.apache.org/jira/browse/ISIS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood updated ISIS-2557:
--------------------------------------
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).
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.
was:
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.
> 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).
>
> 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)
