If you don't know at all about your users (like a public website) you'll need a non protected page for the selft registration. But if you know a little about your users, like for an intranet, extranet application; when users are already registered in an LDAP or any kind of Authentication Provider, you can do that differently.
In this last scenario, you can move authentication and basic autorization access to Apache as proxy with LDAP or Google or ... To receive the userid in the app, you'll need the AJP connector. You can keep secured resources in your app, and even have many more than one (in my apps I have one per business function, quite a lot). Keep authorization and authentication outside of the app allows : - request don't even touch any part of your app (not even a filter) if the user does not have the right to do it. - keep business function independent of role (role and organization always changes, while business remain the same) helps to focus of real business - no access to authorization provider => no risk of "corruption" (ex: self accreditation) - no access to autentication provider => no risk of "corruption" (ex: hack password of others) In this scenario, you'll have to trust Tomcat and Apache and LDAP and Google, and OAUTH2 ... in the ability to perform a proper secured ... authentication and autorization. About the auto-registration, it's a bit tricky because: - your application will receive the login only if the resource is secured - your secured resources will be executed only if tomcat realm says you have the given role => but you can't access as you're not yet registered in Tomcat Realm ! End of the game ? No! The solutions (I found so far) are : - to connect tomcat to the authorization provider (become dependent of the LDAP structure and introduce risk) could be also a little slow (several accesses to the LDAP, or OAUTH2, ...for each request) - to create : - a registration resource (servlet), secured with a "AUTO-REGISTER" role, which insert the user in your tomcat realm - your own tomcat realm (extends JDBC one) saying yes to every user when checking this "AUTO-REGISTER" role. (as your app can only be accessed by authenticated user that looks clean) - then you have other roles for other resources as usual... Stephane -----Original Message----- From: Alex O'Ree <alexo...@apache.org<mailto:Alex%20O'ree%20%3calexo...@apache.org%3e>> Reply-To: Tomcat Users List <users@tomcat.apache.org<mailto:tomcat%20users%20list%20%3cus...@tomcat.apache.org%3e>> To: Tomcat Users List <users@tomcat.apache.org<mailto:tomcat%20users%20list%20%3cus...@tomcat.apache.org%3e>> Subject: Re: user self registration/account creation Date: Tue, 8 Oct 2019 22:05:01 -0400 thanks i'll look into it On Mon, Oct 7, 2019 at 3:36 AM Mark Thomas <ma...@apache.org<mailto:ma...@apache.org>> wrote: On 06/10/2019 20:31, Alex O'Ree wrote: i have a password protected web app and would like to provide users with the ability to self register for a new account. looks like the easiest way to do this with tomcat is with a jdbc realm to protect the web app and anonymous access to the self registration app. a few questions on this. is there a pre made app that could be used for the user account creation app? i'll probably need something for admins to revoke accounts, disable accounts, edit role memberships etc. ugh, and then there is user password resets and complexity requirements... some kind of captcha thing to prevent bots. i also need to track and report to the user when a password expires, last login ip address and user agent field. quite a bit of stuff to write. if there is something available that is asf license compatible, i'd love to hear about it. CAS: https://www.apereo.org/projects/cas I think CAS does everything you asked for. Spring Security is the other option that comes to mind but my understanding is that you'd need to build some of the management UIs yourself. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
