anchor.diff:  
   SecMan consists of a number of Maven submodules:
   
  -* the API module (`isis-extensions-secman-api`) defines a set of interfaces for the xref:refguide:extensions:index/secman/api/user/dom/ApplicationUser.adoc[ApplicationUser], xref:refguide:extensions:index/secman/api/role/dom/ApplicationRole.adoc[ApplicationRole],
  -xref:refguide:extensions:index/secman/api/permission/dom/ApplicationPermission.adoc[ApplicationPermission] and xref:refguide:extensions:index/secman/api/tenancy/dom/ApplicationTenancy.adoc[ApplicationTenancy] entities.
  +* the API module (`isis-extensions-secman-api`) defines a set of interfaces for the xref:refguide:extensions:index/secman/applib/user/dom/ApplicationUser.adoc[ApplicationUser], xref:refguide:extensions:index/secman/applib/role/dom/ApplicationRole.adoc[ApplicationRole],
  +xref:refguide:extensions:index/secman/applib/permission/dom/ApplicationPermission.adoc[ApplicationPermission] and xref:refguide:extensions:index/secman/applib/tenancy/dom/ApplicationTenancy.adoc[ApplicationTenancy] entities.
   
   * the two persistence modules (`isis-extensions-secman-persistence-jpa` and `isis-extensions-secman-persistence-jdo`) provide concrete implementations of the APIs for JPA and JDO respectively.
   As you might expect, they are intended for use with xref:pjpa:ROOT:about.adoc[JPA/Eclipselink] and xref:pjdo:ROOT:about.adoc[JDO/DataNucleus] persistence mechanisms respectively; use one or the other.
  
positive.code: * The `AuthenticatorShiro` calls to the Shiro Security Manager to obtain the authenticated principal.
  * The Shiro Security Manager uses the `shiro.ini` configuration file to look up the realm to perform the authentication; in this case we configure it to use Secman's realm (xref:refguide:extensions:index/secman/shiro/IsisModuleExtSecmanShiroRealm.adoc[IsisModuleExtSecmanShiroRealm]).
  * Secman's realm implementation queries the database and uses this to create an instance of `PrincipalForApplicationUser`, where the `Principal` interface is Shiro's representation of an authenticated user.
  The `PrincipalForApplicationUser` is backed by xref:refguide:extensions:index/secman/api/user/dom/ApplicationUser.adoc[ApplicationUser], which all of the permissions to object members for this particular user.
  * to render a page, the Apache Isis viewer uses configured `Authorizor`, in this case
  Secman's own xref:refguide:extensions:index/secman/api/authorizor/AuthorizorSecman.adoc[AuthorizorSecman].
  This looks up the current xref:refguide:extensions:index/secman/api/user/dom/ApplicationUser.adoc[ApplicationUser] (which will already reside in-memory) and renders the page according to which object members are visible or not.
  
  
  The above configuration allows Secman to be used to authenticate users; the password is stored as an (typically) encrypted property of the xref:refguide:extensions:index/secman/api/user/dom/ApplicationUser.adoc[ApplicationUser].
  These are called "local" users, as per the xref:refguide:extensions:index/secman/api/user/dom/ApplicationUser.adoc[ApplicationUser]'s `accountType` property.
  
  Secman's xref:refguide:extensions:index/secman/shiro/IsisModuleExtSecmanShiroRealm.adoc[Realm implementation] also allows a "delegate" realm to be configured.
  In such cases the authentication of "delegated" users is performed by the delegate realm rather than locally.
  
negative.code:     }
  }
  ----
  <.> SecMan provides the xref:refguide:extensions:index/secman/applib/tenancy/dom/HasAtPath.adoc[HasAtPath] interface to standardize the way in which domain objects expose their "tag" (atPath) to the evaluator.
  <.> can view all objects (above and below) within the user's hierarchy
  +
  For example:
  