Got it! You have a few options, but the most straightforward might be to lump all of this logic into a single Realm (that realm could delegate to a JDBC realm or AD realm) This new realm would perform a query to see where the user needed to authenticate from (local DB or AD), then add the permission to the user (or delegate that to another DB realm)
CustomRealm └ DB Realm or AD Realm (authenticate) └ DB Realm (authorize) Or... getting slightly more involved, but moving the logic. You could create a Shiro `Authenticator` which contains the logic to check if you need to authenticate via your DB or AD. And a Shiro `Authorizor` that just delegates to a DB realm to add the permissions to your Subject. See DefaultSecurityManager's `setAuthorizator()` and `setAuthenticator()` Does that help? On Mon, Apr 30, 2018 at 10:40 AM, Debug82 <[email protected]> wrote: > Hello Brian, > > First, Thank you for your reply. > > To be more specific, here are some details: > I am implementing a REST API (security app) that manages authentication and > authorization of multiple applications (mainly web applications) with a > local database to persist managed applications, users, groups, roles and > permissions (roles and permissions are associated with a particular > application) > > - User and Group entities have a "isDirectory" field that tells us if the > user/group is created in our security app or is imported from a directory. > When the user/group should be imported from a directory, there are other > fileds that are required in the record (like the url, ...etc) to be able to > connect to this AD instance. > > - For authentication purpose, one application may have to talk to multiple > AD instances (not federated) [when a user/group isDirectory=true). The user > can as well be created in my [local] security app database > > - If a user is an AD, some of its information will be loaded to the local > database (like username and first name) > > - All authorization information (permissions) are created in my local > security app database. That means that the authorization can only be > performed against my local database > > Please let me know if it is clear. > > Regards > > > > -- > Sent from: http://shiro-user.582556.n2.nabble.com/ >
