...
Unconfirmed entries cannot be used for authentication.
Use:
- User goes to /selfreg/index.html and receives a form
- Fills in the form receives an email.
- Follows the link to confirm.
Configuration
Selfreg requires a database to hold data about users. If ldap authentication is desired the ldap parameters need to be set in the configuration. In both cases ensure an appropriate database has been created and there is a datasource present. There are sample data sources in the bedework/config/datasources directory. The datasource is used both by the selfreg module and by the DatabaseServerLoginModule if db authentication is desired.
...
- Message Digest - set exactly to the value in the hashAlgorithm element below, SHA, MD5 are acceptable
- Account prefix - the accounts created may be the only accounts for your system in which case leave this empty. If you have multiple sets of accounts you need to ensure they will not overlap. Set this to a value that ensures that. For example, if all your accounts are 2 letters + 4 digits then prefixing with any letter will work. Selfreg generates acounts of that form in the absence of a prefix.
- ConfirmUrl - this is what prefixes the url to confirm the creation. Something of the form http://localhost:8080/selfreg - the host, port and context.
DatabaseServerLoginModule
This is the standard jboss module. For jboss 5 add the following to the login-config.xml file
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<application-policy name="bwselfreg"> |
...
<authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> |
...
<module-option name="dsJndiName" |
...
>java:/ |
...
selfregDS</module-option> |
...
<module-option name="principalsQuery">select bw_pw from bw_accounts where bw_account=? and bw_enabled='T'</module-option> |
...
<module-option name="rolesQuery">select bw_role, 'Roles' from bw_roles where bw_account=?</module-option> |
...
<module-option name="hashAlgorithm">SHA</module-option> |
...
<module-option name="hashEncoding">base64</module-option> |
...
</login-module> |
...
</authentication> </application-policy> |
For Wildfly add the following in the security-domains
| Code Block | ||||
|---|---|---|---|---|
| ||||
<security-domain name="bwselfreg"> <authentication> <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="java:/selfregDS"/> <module-option name="principalsQuery" value="select bw_pw from bw_accounts where bw_account=? and bw_enabled='T'"/> <module-option name="rolesQuery" value="select bw_role, 'Roles' from bw_roles where bw_account=?"/> <module-option name="hashAlgorithm" value="SHA"/> <module-option name="hashEncoding" value="base64"/> < |
...
/login-module>
</authentication>
</security-domain> |
Flow of messages
As usual with these we use a combination of web pages, captcha and email to try to produce a secure transaction. Fields of importance are the email, userid, a confirmation id (confid), current password (curPw), new password (newPw)
New unregistered user
- Go to register form.
- Fill in all the details.
- Submit to /newid
- New entry added with a new confid and timestamp.
- email sent to user with confirmation link.
- user clicks on link - goes to /confirm
- account enabled - confid changed to new random value.
- response message sent.
Forgot password
- Go to forgot password page
- Enter account + submit to /fpw
- New confid set in entry
- email sent to user with confid
- user clicks link - submit to a newpw page configured in jmx with confid as request parameter and with new password input area.
- submits to /setpw - need confid and password
- password updated - message sent
If a malevolent user starts the process they need not only the account but access to the users email.
Forgot Id
- Go to forgot id page (possibly the same page)
- Enter their email address.
- Submit to /fid
- Email with userid sent to that email.
- If they don't know the password can use the forgot password.