On 8 Oct 2010, at 17:09 , Ivo Ladage-van Doorn wrote: > While analyzing the code of the UserAdmin implementation, Angelo and I found > a interesting issue. The problem in this case is that the UserAdmin service > should create an initial user (i.e. ?Administrator?) upon the very first time > this service is started. This user is required for first boot, after that the > Admin will probably change its password or create new users and delete this > one.
Who actually requires this user? If it's just a way to bootstrap the creation of other users? In any case, this is something that's definitely not the responsibility of User Admin, but dependent on what your application actually needs. I think the actual use case here is something like: what should happen if there is no user defined? This can happen because it's the first time the application starts, or because some smart-ass administrator actually threw away all accounts including his own. > Now the service needs to know when to create this user. Depending on application requirements: when there is no user, or when there is no user with admin rights, or ... > Currently this is done by storing a ?INITIALIZED? configuration in > ConfigAdmin,, sets it to true and the next time it starts it will skip > creation of the admin user since this property is ?true?. In general, how > should we cope with this? Setting this INITIALIZED configuration property in > ConfigAdmin is not the proper way (it should be read-only), but how should > this be implemented? Anyone any ideas? Somewhere in the appliation code that contains the user management logic I would embed code that supports creating an "admin" account with a password that probably immediately expires (upon first login). Another option is to always allow a certain username and password to access the application *if* there are no users. One could even consider the scenario where there is a single admin account, but somehow someone forgot the password (and there is no mechanism to e-mail it or anything). In such cases, one could consider logic that allows a user to log in using a "synthetic" account (one not actually in User Admin) with a special password. That special password should change on a daily (or hourly) basis and it should only be possible for "our support desk" to generate it. Generating it does not physically means changing any configuration, it should be a password based on for example the target ID and the day of the year and some magic number all thrown together. Probably too complicated for now. So, I would stick with some code that creates a default admin account if there is no user with admin role, and I would put that in some application specific bundle, not in UserAdmin or in the core of Amdatu. Greetings, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101008/b212aa0a/attachment.html
