If additional views/URLs need to be exposed, an active {@link SecurityRealm} is bound to CONTEXT_ROOT/securityRealm/through {@link jenkins.model.Jenkins#getSecurityRealm()}, so you can define additional pages and operations on your {@link SecurityRealm}.
For compatibility reasons, there are two somewhat different ways to implement a custom SecurityRealm.
One is to override the {@link #createSecurityComponents()} and create key Acegi componentsthat control the authentication process. The default {@link SecurityRealm#createFilter(FilterConfig)} implementation then assembles theminto a chain of {@link Filter}s. All the incoming requests to Hudson go through this filter chain, and when the filter chain is done, {@link SecurityContext#getAuthentication()} would tell uswho the current user is.
If your {@link SecurityRealm} needs to touch the default {@link Filter} chain configuration(e.g., adding new ones), then you can also override {@link #createFilter(FilterConfig)} to do so.
This model is expected to fit most {@link SecurityRealm} implementations.
The other way of doing this is to ignore {@link #createSecurityComponents()} completely (by returning{@link SecurityComponents} created by the default constructor) and just concentrate on {@link #createFilter(FilterConfig)}. As long as the resulting filter chain properly sets up {@link Authentication} object at the end of the processing,Hudson doesn't really need you to fit the standard Acegi models like {@link AuthenticationManager} and{@link UserDetailsService}.
This model is for those "weird" implementations.
|
|
|
|
|
|