search

crhume / pwm

Automatically exported from code.google.com/p/pwm
0 stars 0 forks source link

Require authentication before new user registration (allow only registered user group to add new users) #39

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Enable and configure "New User Registration"
2. New User Registration is available to anyone

What is the expected output? What do you see instead?

Currently New User Registration is available to anyone. We'd like to add 
options to allow New User Registration only to certain registered users.

What version of the product are you using? On what operating system?

Revision 110, any OS.

Please provide any additional information below.

We'll provide some new code. We'll add options to PwmSettings.java for:
* Requirement to authenticate (Boolean)
* Group DN that is allowed to register new users
* Attribute used to register the (responsible) logged in user

We'll add code to NewUserServlet.java/processRequest(...) in order to check for 
authentication, group membership, and set the attribute value, use the logged 
in user's credentials for LDAP communication (in stead of proxy user).

We'll add new variables to PwmSettings.properties to define the form changes.

Am I forgetting something?

Original issue reported on code.google.com by menno.pi...@gmail.com on 27 Feb 2011 at 9:52

GoogleCodeExporter commented 9 years ago 
Not sure I'm following....  Is this for something other than new user _self_ 
registration?  This sounds like a case where a helpdesk or other 3rd party is 
creating user accounts.  

In that case, it does not sound appropriate to modify the NewUserRegistration 
portlet.  Instead, this would be the start of a helpdesk or admin user module...

Original comment by jrivard on 28 Feb 2011 at 5:36

GoogleCodeExporter commented 9 years ago 
That is correct.

Sounds OK to me, too. Could you give me some hints on where to start? I
assume I could reuse a lot of code, right?

Original comment by menno.pi...@gmail.com on 28 Feb 2011 at 7:02

GoogleCodeExporter commented 9 years ago 
Probably.. I would guess a new standalone servlet is required 
/pwm/private/HelpDesk ?

We could look to the /admin pages for inspiration on navigation.... as for 
code, there's probably a lot to reuse from bits and places.

I can't help but wonder though, aren't there already lots of admin utilities 
out there to handle this sort of thing?  I can see /password/ related helpdesk 
functions being useful in pwm, but having pwm become a general purpose helpdesk 
tool isn't something I ever envisioned.  

Project isn't limited to my own vision though :)

Original comment by jrivard on 28 Feb 2011 at 8:56

GoogleCodeExporter commented 9 years ago 
I'll explain a bit... Novell recommended using PWM as a replacement for
their own User Application, because we wanted to do things that would
require changes in the application that would in turn void support: add JSP
pages to replace the default password recovery and send e-mail and/or SMS
with a code. PWM can do the trick.

The new user registration is in our case not intended for "normal" users.
They will be provisioned by identity manager from other sources with a lot
more attributes. The new user registration is intended for short lived guest
accounts. It could therefore be rather simple. Additional attributes and
logic can be applied by the identity manager.

Original comment by menno.pi...@gmail.com on 28 Feb 2011 at 9:27

GoogleCodeExporter commented 9 years ago 
So... in this case, it is still a known user doing the creation, perhaps a 
manager or some other type of existing user account.  So I guess it falls more 
towards my helpdesk concept but not quite exactly.

In the Novell world, I'd recommend that this sort of thing be implemented using 
a no-approval workflow in the RBPM UserApp.  That's the intended interface for 
this sort of use case.

Your welcome to add on to pwm, and if you do your welcome (okay, begged!) to 
submit the code, but not sure when or how I'll try to merge this functionality 
to pwm.  If your going to proceed with pwm, I'd recommend documenting the 
design first and mocking up UI for discussion in this issue or on the pwm list.

Original comment by jrivard on 1 Mar 2011 at 3:51

GoogleCodeExporter commented 9 years ago 

On Mar 1, 4:51 am, p...@googlecode.com wrote:
> Comment #5 on issue 39 by jrivard: Require authentication before new user  
> registration (allow only registered user group to add new 
users)http://code.google.com/p/pwm/issues/detail?id=39
> 
> So... in this case, it is still a known user doing the creation, perhaps a  
> manager or some other type of existing user account.  So I guess it falls  
> more towards my helpdesk concept but not quite exactly.
> 
> In the Novell world, I'd recommend that this sort of thing be implemented  
> using a no-approval workflow in the RBPM UserApp.  That's the intended  
> interface for this sort of use case.

We don't want to do "no-approval", but only allow selected users to register 
guests. Of course RBPM is a lot more powerful, but it's nice to have one 
interface and PWM is a lot easier to configure (and hack without voiding 
warranty ;-))

> Your welcome to add on to pwm, and if you do your welcome (okay, begged!)  
> to submit the code, but not sure when or how I'll try to merge this  
> functionality to pwm.  If your going to proceed with pwm, I'd recommend  
> documenting the design first and mocking up UI for discussion in this issue  
> or on the pwm list.

Let's take this approach: you worry about the when, I'll worry about the how. 
I'll keep te code as close as possible to the current revision when submitting, 
so it won't be difficult to merge.

About the design. 
----------------------

What we want:
* A simple interface, where a registered user, a member of a specific group, 
can create a new guest user.
* The form/interface should be similar to the New User Form
* It should be possible to hide the Guest Registration from the main menu 
(option)

What we need to do:
* Add a configuration category "GUEST"
* Add configuration options for this category:
  * Enable/disable
  * Hide
  * Container in which the users should be created
  * Group DN for users who are allowed to create the guest accounts
  * The form definition
  * Unique attributes
  * Automatically filled in attribute values
  * Attribute in which the logged in user's DN should be stored
* Create a form and bean that handles the user creation with the logged in 
user's credentials
* Add an entry to the main menu
* Update documentation

Original comment by menno.pi...@gmail.com on 1 Mar 2011 at 8:29

GoogleCodeExporter commented 9 years ago 
I've been working on a patch for the last couple of days. It's a separate 
function now, a new entry in the menu and it WORKS :-) Patch (against r111) and 
new files attached.

This is a start, because I want to add some more functionality:
* A date input field, perhaps for different date formats (seconds since 1970, 
generalized time stamp)
* Edit/Update Guest User

One problem, I came accross is that LDAPChai can use only one objectClass for 
creation of a new user. Because my setup uses some non-standard attributes, I 
had to create a "super class" of a number of objectClasses and use that class. 
I've made a small modification for that in the LDAP section.

I hope you'll review/merge the code.

Best regards,

Menno

Original comment by menno.pi...@gmail.com on 4 Mar 2011 at 10:54

GoogleCodeExporter commented 9 years ago 
An updated patch for r113. The other/new files are unchanged.

Original comment by menno.pi...@gmail.com on 6 Mar 2011 at 9:29

GoogleCodeExporter commented 9 years ago 
Looks like a great patch menno.  However I'd like to get v1.5.3 out the door 
before we merge this in and begin to add these types of functions for v1.5.4.  
v1.5.3 is pretty close to be wrapped up I think....

Original comment by jrivard on 9 Mar 2011 at 6:04

GoogleCodeExporter commented 9 years ago 
Hi Jason,

Yes, it seems quite stable right now. I'm afraid I'll have to keep patching
my version for a while.

Original comment by menno.pi...@gmail.com on 9 Mar 2011 at 6:40

GoogleCodeExporter commented 9 years ago 
Now that 1.5.3 is out, I guess I can submit my changes again. These are patches 
and additional files for the latest SVN revision.

Please review my changes.

Best regards,

Menno Pieters

Original comment by menno.pi...@gmail.com on 5 Apr 2011 at 8:38

Attachments:

GoogleCodeExporter commented 9 years ago 
Some clarification to my changes:
* Of course added the required configuration category and items, as well as 
strings for localisation
* Added beans to the PwmSession
* Added a number validator to the Validator.java for upper/lower bounds
* Added a new input type RANDOM, that is actually a string, but pre-filled with 
a generated token.
* Added a helper routine to generate the above token
* Added a helper routine to fill in attribute values into email messages sent 
to new users/guests. 
* Added the possibility to set the object class(es) to be used for new user and 
guest registration
* Added new servlets and beans for guest registration and modification.
* Updated index.jsp

Original comment by menno.pi...@gmail.com on 5 Apr 2011 at 9:24

GoogleCodeExporter commented 9 years ago 
Merged into svn revision 136.  I plan on doing more refactoring however, I 
would especially like to see if the two new servlets could be merged into a 
single servlet...

Original comment by jrivard on 23 Apr 2011 at 1:32

GoogleCodeExporter commented 9 years ago 
You mean the new user and new guest... That was my original plan, but you
suggested to make a separate function, which in the end, I think is better.
Both functions are quite similar, that's true. Perhaps inheriting functions
could help.

Thanks for updating the source!

Original comment by menno.pi...@gmail.com on 23 Apr 2011 at 9:22

GoogleCodeExporter commented 9 years ago 
Ah..Indeed new user/new guest should be separate.  I was meaning 
newguest/update guest could be merged.  But I need to study the code more.  I'm 
still a bit weary of the overall usecase personally, but I guess that's not 
important :)   In all though, I'm glad for the addition!  Closing this issue, 
if there's functionality issues well discuss on the list or open new issues.  
Great patch!

Original comment by jrivard on 24 Apr 2011 at 1:35

GoogleCodeExporter commented 9 years ago 
Issue 242 has been merged into this issue.

Original comment by menno.pi...@gmail.com on 18 Jul 2012 at 6:37