aMapApp3 makes use of the concept of authority levels that control what a particular user can do within the MapApp environment. While powerful, this makes the problem of authenticating users more complicated.
There are three methods of handling user authentication. The first involves using the aLogin2 software package that is automatically setup when MapApp is added to an application. aLogin2 includes the concept of authority levels in its design. You can designate a login <div> tag at creation time which will hold a Login link and an optional New Account link, but aLogin2 can be made to work without this tag.
The second approach is to write code that accesses another authentication system and which can be plugged into the aLogin2 software. The aLogin2 code was written specifically to allow this. How this is done is outlined in the aLogin2 documentation. The critical thing to remember is that the final result of the authentication process must include an authority level. For example, you could use aLogin2 to create accounts and manage logins, but write code that would check users against an external database to make sure they mean additional requirements. Another example would involve having authentication done before the web application runs, such as provided by use of a .htaccess file, then modifying the aLogin2 authentication code to supply authority levels.
The third approach is simply to replace the aLogin2 code completely. This would require that the code that is being used is written such away as that it can interface with the rest of MapApp, usually by replicating interface elements used to talk between aMapApp3, aLogin2 and aBlog2. To be honest, we've never tried this.