此内容没有您所选择的语言版本。
Chapter 15. Extending the Hierarchical Database
You can create customized extensions to the hierarchical database. To do so you will need to write Java code, and to use Maven 3 for the build system.
15.1. Custom Authentication and Authorization Modules 复制链接链接已复制到粘贴板!
复制链接链接已复制到粘贴板!
15.1.1. The AuthenticationProvider Interface 复制链接链接已复制到粘贴板!
复制链接链接已复制到粘贴板!
The hierarchical database defines a simple interface for authenticating users. Each repository can have multiple authentication modules, and a client is authenticated as soon as one of the modules accepts the credentials. The interface is quite simple:
All the parameters are supplied by the hierarchical database and contain everything necessary to authenticate a client attempting to create a new JCR Session.
Implementations are expected to return a new
ExecutionContext
instance for the user, and this can be created from the repository's execution context by calling repositoryContext.with(securityContext)
, where securityContext
is a custom implementation of the org.modeshape.jcr.security.SecurityContext
interface that returns information about the authenticated user:
Note that if you want to provide authorization functionality, then your
SecurityContext
implementation must also implement AuthorizationProvider
or AdvancedAuthorizationProvider
.
15.1.2. The AuthorizationProvider Interface 复制链接链接已复制到粘贴板!
复制链接链接已复制到粘贴板!
The hierarchical database uses its
org.modeshape.jcr.security.AuthorizationProvider
interface to determine whether a Session has the appropriate privileges to perform reads and writes.
You can have your
SecurityContext
implementation also implement this interface, and return true
whenever the session is allows to perform the requested operations.
15.1.3. The AdvancedAuthorizationProvider Interface 复制链接链接已复制到粘贴板!
复制链接链接已复制到粘贴板!
The hierarchical database uses its
org.modeshape.jcr.security.AdvancedAuthorizationProvider
interface to determine whether a Session has the appropriate privileges to perform reads and writes.
where
Context
is a new nested interface nested in AdvancedAuthorizationProvider
:
You can have your
SecurityContext
implementation also implement this interface, and return true
whenever the session is allows to perform the requested operations.
Once you've implemented the interfaces and placed the classes on the classpath, all you have to do is then configure your repositories to use your modules. As noted in the "configuration overview" , there is a nested document in the JSON configuration file in the
security
field, and this section lists the authentication module implementations in the order that they should be used . For example:
This configuration enables the use of anonymous logins (although it disables a failed authentication attempt from downgrading to an anonymous session with the
useOnFailedLogin
as false
), and configures two authentication providers: the MyAuthenticationProvider
implementation will be used first, and if that does not authenticate the repository will delegate to the built-in JAAS provider. (Note that built-in providers can be referenced with an alias in the classname
field rather than the fully-qualified classname.) Anonymous authentication is always performed last.