public abstract class AbstractPasswordBasedSecurityRealm extends SecurityRealm implements org.acegisecurity.userdetails.UserDetailsService
SecurityRealmfor username/password based authentication. This is a convenience base class if all you are trying to do is to check the given username and password with the information stored in somewhere else, and you don't want to do anything with Acegi.
SecurityRealm uses the standard login form (and a few other optional mechanisms like BASIC auth)
to gather the username/password information. Subtypes are responsible for authenticating this information.
|Constructor and Description|
|Modifier and Type||Method and Description|
Authenticate a login attempt.
Retrieves information about a group by its name.
Retrieves information about an user by its name.
all, allowsSignup, canLogOut, commenceSignup, createCliAuthenticator, createFilter, doCaptcha, doLogout, findBean, getAuthenticationGatewayUrl, getCaptchaSupport, getCaptchaSupportDescriptors, getDescriptor, getFrom, getGroupIdStrategy, getLoginUrl, getPostLogOutUrl, getSecurityComponents, getUserIdStrategy, loadGroupByGroupname, setCaptchaSupport, validateCaptcha
public SecurityRealm.SecurityComponents createSecurityComponents()
AuthenticationManagerthat performs authentication against the user realm. The implementation hides how such authentication manager is configured.
AuthenticationManager instantiation often depends on the user-specified parameters
(for example, if the authentication is based on LDAP, the user needs to specify
the host name of the LDAP server.) Such configuration is expected to be
presented to the user via
config.jelly and then
captured as instance variables inside the
protected abstract org.acegisecurity.userdetails.UserDetails authenticate(String username, String password) throws org.acegisecurity.AuthenticationException
If the user name and the password pair matches, retrieve the information about this user and
return it as a
User is a convenient
implementation to use, but if your backend offers additional data, you may want to use your own subtype
so that the rest of Hudson can use those additional information (such as e-mail address --- see
UserDetails.getPassword() make no sense, so just return an empty value from it.
The only information that you need to pay real attention is
is a list of roles/groups that the user is in. At minimum, this must contain
(which indicates that this user is authenticated and not anonymous), but if your backend supports a notion
of groups, you should make sure that the authorities contain one entry per one group. This enables
users to control authorization based on groups.
If the user name and the password pair doesn't match, throw
AuthenticationException to reject the login
public abstract org.acegisecurity.userdetails.UserDetails loadUserByUsername(String username) throws org.acegisecurity.userdetails.UsernameNotFoundException, org.springframework.dao.DataAccessException
This method is used, for example, to validate if the given token is a valid user name when the user is configuring an ACL.
This is an optional method that improves the user experience. If your backend doesn't support
a query like this, just always throw
public abstract GroupDetails loadGroupByGroupname(String groupname) throws org.acegisecurity.userdetails.UsernameNotFoundException, org.springframework.dao.DataAccessException
Copyright © 2004–2019. All rights reserved.