You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by da...@apache.org on 2021/04/08 06:02:44 UTC

[isis] branch 2.0.0-M5 updated (739aa6a -> cb0c1f6)

This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a change to branch 2.0.0-M5
in repository https://gitbox.apache.org/repos/asf/isis.git.


    from 739aa6a  ISIS-2484: adds docs on security implementations
     new 9f5b0ba  ISIS-2484: updates shiro
     new f4bb021  ISIS-2484: removes 'run-as' hint for shiro
     new cb0c1f6  ISIS-2484: removes the commented-out docs on jdbc realm for shiro.

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../src/main/adoc/modules/shiro/pages/about.adoc   | 227 ++-------------------
 1 file changed, 16 insertions(+), 211 deletions(-)

[isis] 03/03: ISIS-2484: removes the commented-out docs on jdbc realm for shiro.

Posted by da...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a commit to branch 2.0.0-M5
in repository https://gitbox.apache.org/repos/asf/isis.git

commit cb0c1f6a4791fa2ab57ab551892acee01827b044
Author: danhaywood <da...@haywood-associates.co.uk>
AuthorDate: Thu Apr 8 07:02:01 2021 +0100

    ISIS-2484: removes the commented-out docs on jdbc realm for shiro.
    
    jdbc realm does not (I think) support enhanced permissions resolver
---
 .../src/main/adoc/modules/shiro/pages/about.adoc   | 107 ---------------------
 1 file changed, 107 deletions(-)

diff --git a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
index 4ce8e00..91fb900 100644
--- a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
+++ b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
@@ -233,113 +233,6 @@ Instead, the corresponding sections from for `realm1.ini` are used instead.
 ====
 
 
-//== Shiro JDBC Realm
-//
-//There is nothing to stop you from using some other `Realm` implementation (or indeed writing one yourself).
-//For example, you could use Shiro's own JDBC realm that loads user/password details from a database.
-//
-//[WARNING]
-//====
-//If you are happy to use a database then we strongly recommend you use the xref:security:ROOT:about.adoc[SecMan extension] instead of a vanilla JDBC; it is far more sophisticated and moreover gives you the ability to administer the system from within your Apache Isis application.
-//====
-//
-//If you go down this route, then the architecture is as follows:
-//
-//image::configuration/configuring-shiro/jdbc/configure-shiro-to-use-custom-jdbc-realm.png[width="600px"]
-//
-//
-//
-//
-//There's quite a lot of configuration required (in `shiro.ini`) to set up a JDBC realm, so we'll break it out into sections.
-//
-//First, we need to set up the connection to JDBC:
-//
-//[source,ini]
-//----
-//jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm        # <.>
-//
-//jof = org.apache.shiro.jndi.JndiObjectFactory          # <.>
-//jof.resourceName = jdbc/postgres                       # <.>
-//jof.requiredType = javax.sql.DataSource
-//jof.resourceRef = true
-//
-//jdbcRealm.dataSource = $jof                            # <4>
-//----
-//<1> instantiate the JDBC realm
-//<2> instantiate factory object to lookup DataSource from servlet container
-//<3> name of the datasource (as configured in `web.xml`)
-//<4> instruct JDBC realm to obtain datasource from the JNDI
-//
-//
-//We next need to tell the realm how to query the database.Shiro supports any schema; what matters is the input search argument and the output results.
-//
-//[source,ini]
-//----
-//
-//jdbcRealm.authenticationQuery =         \              # <1>
-//        select password                 \
-//          from users                    \
-//         where username = ?
-//
-//jdbcRealm.userRolesQuery =              \              # <2>
-//        select r.label                  \
-//          from users_roles ur           \
-//    inner join roles r                  \
-//            on ur.role_id = r.id        \
-//         where user_id = (              \
-//            select id                   \
-//             from users                 \
-//            where username = ?);        \
-//
-//jdbcRealm.permissionsQuery=             \               # <3>
-//        select p.permission             \
-//          from roles_permissions rp     \
-//    inner join permissions p            \
-//            on rp.permission_id = p.id  \
-//         where rp.role_id = (           \
-//            select id                   \
-//             from roles                 \
-//            where label = ?);
-//
-//jdbcRealm.permissionsLookupEnabled=true                 # <4>
-//----
-//<1> query to find password for user
-//<2> query to find roles for user
-//<3> query to find permissions for role
-//<4> enable permissions lookup
-//
-//[WARNING]
-//====
-//The `permissionsLookupEnabled` is very important, otherwise Shiro just returns an empty list of permissions and your users will have no access to any features(!).
-//====
-//
-//We also should ensure that the passwords are not stored as plain-text:
-//
-//[source,ini]
-//----
-//dps = org.apache.shiro.authc.credential.DefaultPasswordService   # <1>
-//pm = org.apache.shiro.authc.credential.PasswordMatcher           # <2>
-//pm.passwordService = $dps
-//jdbcRealm.credentialsMatcher = $pm                               # <3>
-//----
-//<1> mechanism to encrypts password
-//<2> service to match passwords
-//<3> instruct JDBC realm to use password matching service when authenticating
-//
-//
-//And finally we need to tell Shiro to use the realm, in the usual fashion:
-//
-//[source,ini]
-//----
-//securityManager.realms = $jdbcRealm
-//----
-//
-//Using the above configuration you will also need to setup a `DataSource`.The details vary by servlet container, for example this is link:https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html[how to do the setup on Tomcat 8.0].
-//
-//[WARNING]
-//====
-//The name of the `DataSource` can also vary by servlet container; see for example link:http://stackoverflow.com/questions/17441019/how-to-configure-jdbcrealm-to-obtain-its-datasource-from-jndi/23784702#23784702[this StackOverflow answer].
-//====
 
 
 [#enhanced-wildcard-permission]

[isis] 01/03: ISIS-2484: updates shiro

Posted by da...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a commit to branch 2.0.0-M5
in repository https://gitbox.apache.org/repos/asf/isis.git

commit 9f5b0ba31bb0a231b1791ee82fbc599009b1ec42
Author: danhaywood <da...@haywood-associates.co.uk>
AuthorDate: Thu Apr 8 06:59:55 2021 +0100

    ISIS-2484: updates shiro
---
 .../src/main/adoc/modules/shiro/pages/about.adoc   | 31 ++++++++++++++--------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
index f6be470..c7cf0d0 100644
--- a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
+++ b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
@@ -85,7 +85,6 @@ securityManager.realms = $realmName
 ----
 
 Shiro's ini file supports a "poor-man's" dependency injection (link:https://shiro.apache.org/configuration.html[their words]), and so `$realmName` in the above example is a reference to a realm defined elsewhere in `shiro.ini`.
-The subsequent sections describe the specifics for thevarious realm implementations available to you.
 
 It's also possible to configure Shiro to support multiple realms.
 
@@ -97,6 +96,9 @@ securityManager.realms = $realm1,$realm2
 How to configure the text-based ini realm is explained <<shiro-ini-realm,below>>.
 Another option lternative is the xref:security:shiro-realm-ldap:about.adoc[LDAP realm].
 
+To leverage Apache Isis' <<enhanced-wildcard-permission,enhanced wildcard permissions>>, you should also specify the Apache Isis permission resolver for the specified realm; further details <<permission-resolver-configuration,below>>.
+
+
 
 [#shiro-ini-realm]
 == Shiro Ini Realm
@@ -369,37 +371,44 @@ For example:
 
 [source,ini]
 ----
-user_role   = !reg/org.estatio.api,\
-              !reg/org.estatio.webapp.services.admin,\
+user_role   = !reg/com.mycompany.myapp.api,\
+              !reg/com.mycompany.myapp.webapp.services.admin,\
               reg/* ; \
-api_role    = org.estatio.api ;\
+api_role    = com.mycompany.myapp.api ;\
 admin_role = adm/*
 ----
 
 sets up:
 
-* the `user_role` with access to all permissions except those in `org.estatio.api` and `org.estatio.webapp.services.admin`
-* the `api_role` with access to all permissions in `org.estatio.api`
+* the `user_role` with access to all permissions except those in `com.mycompany.myapp.api` and `com.mycompany.myapp.webapp.services.admin`
+* the `api_role` with access to all permissions in `com.mycompany.myapp.api`
 * the `admin_role` with access to everything.
 
 The permission group concept is required to scope the applicability of any veto permission.
 This is probably best explained by an example.
 Suppose that a user has both `admin_role` and `user_role`; we would want the `admin_role` to trump the vetos of the `user_role`, in other words to give the user access to everything.
 
-Because of the permission groups, the two "+++!reg/...+""" vetos in user_role only veto out selected permissions granted by the "+++reg/*+++" permissions, but they do not veto the permissions granted by a different scope, namely "+++adm/*+++".
+:asterisk: *
+Because of the permission groups, the two `!reg/...` vetos in `user_role` only veto out selected permissions granted by the ``reg/{asterisk}`` permissions, but they do not veto the permissions granted by a different scope, namely `adm/*`.
 
 The net effect is therefore what we would want: that a user with both `admin_role` and `user_role` would have access to everything, irrespective of those two veto permissions of the `user_role`.
 
-Finally, the Apache Isis permission resolver is specified in `shiro.ini` file:
+[[permission-resolver-configuration]]
+=== Configuration
+
+To configure Apache Isis' extended permission support requires that a custom permission resolver is specified in `shiro.ini` file:
 
 [source,ini]
 ----
 permissionResolver = org.apache.isis.security.shiro.authorization.IsisPermissionResolver
-myRealm.permissionResolver = $permissionResolver  # <1>
+myRealm.permissionResolver = $permissionResolver  # <.>
 ----
-<1> `myRealm` is the handle to the configured realm, eg `$iniRealm` or `$isisLdapRealm` etc.
+<.> `myRealm` is the handle to the configured realm, eg `$iniRealm` or `$isisLdapRealm` etc.
+
+
+== Hints and Tips
 
-== Run-as
+=== Run-as
 
 This hint shows how to temporarily change the current user as reported by Shiro.
 This can be useful to support "Run As", for example.

[isis] 02/03: ISIS-2484: removes 'run-as' hint for shiro

Posted by da...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a commit to branch 2.0.0-M5
in repository https://gitbox.apache.org/repos/asf/isis.git

commit f4bb021c837f5598e707149d7374ced4fd3b24ab
Author: danhaywood <da...@haywood-associates.co.uk>
AuthorDate: Thu Apr 8 07:00:24 2021 +0100

    ISIS-2484: removes 'run-as' hint for shiro
---
 .../src/main/adoc/modules/shiro/pages/about.adoc   | 97 ----------------------
 1 file changed, 97 deletions(-)

diff --git a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
index c7cf0d0..4ce8e00 100644
--- a/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
+++ b/security/shiro/src/main/adoc/modules/shiro/pages/about.adoc
@@ -406,103 +406,6 @@ myRealm.permissionResolver = $permissionResolver  # <.>
 <.> `myRealm` is the handle to the configured realm, eg `$iniRealm` or `$isisLdapRealm` etc.
 
 
-== Hints and Tips
-
-=== Run-as
-
-This hint shows how to temporarily change the current user as reported by Shiro.
-This can be useful to support "Run As", for example.
-
-The heavy lifting is done in `ShiroService`:
-
-[source,java]
-----
-import org.springframework.stereotype.Service;
-
-@Service
-public class ShiroService {
-
-    public void runAs(String userName) {
-        SimplePrincipalCollection principals =
-            new SimplePrincipalCollection(userName, "jdbcRealm");                       // <1>
-        getSubject().runAs(principals);
-    }
-
-    public String releaseRunAs() {
-        final PrincipalCollection principals = getSubject().releaseRunAs();
-        String username = (String)principals.asList().get(0);
-        return username;
-    }
-
-    public String getUsername() {                                                       // <2>
-        String principalAsString = ((String)getSubject().getPrincipal());
-        return principalAsString.toLowerCase();
-    }
-
-    public String getRealUsername() {                                                   // <3>
-        return userService.getUser().getName().toLowerCase();
-    }
-
-    public boolean isRunAs() {
-        return getSubject().isRunAs();
-    }
-
-    private static Subject getSubject() {
-        return org.apache.shiro.SecurityUtils.getSubject();
-    }
-
-    @Inject
-    private UserService userService;
-}
-----
-<1> "jdbcRealm" is realm as configured in Shiro config (shiro.ini).
-<2> The username of the currently logged in user (by which permissions are determined).
-This could be the user name the real user is running as.
-<3> The username of the real currently logged in user.
-
-This could be exposed in the UI using a simple `RunAsService`, for example:
-
-[source,java]
-----
-@DomainService(nature = NatureOfService.VIEW)
-@DomainServiceLayout(menuBar = DomainServiceLayout.MenuBar.TERTIARY)
-public class RunAsService {
-
-    public Dashboard runAs(User user) {
-        shiroService.runAs(user.getUsername());
-        return dashboardService.openDashboard();                    // <1>
-    }
-    public List<User> choices0RunAs() {
-        return ...                                                  // <2>
-    }
-    public boolean hideRunAs() {
-        return shiroService.isRunAs();
-    }
-
-
-
-    public User releaseRunAs() {
-        String username = shiroService.releaseRunAs();
-        return usersRepository.findByUsername(username);
-    }
-    public boolean hideReleaseRunAs() {
-        return !shiroService.isRunAs();
-    }
-
-
-    @Inject
-    private ShiroService shiroService;
-    @Inject
-    private UsersRepository usersRepository;
-    @Inject
-    private DashboardService dashboardService;                      // <1>
-}
-----
-<1> go to the home page (application-specific)
-<2> return a list of users to run as
-
-
-Credits: adapted from link:https://gist.github.com/erikdehair/efa3005440ca982cca41ebe5347e82d8[this gist].
 
 == Caching