Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3FC9BCBA.2030503@mortbay.com>
Date: Sun, 30 Nov 2003 20:47:38 +1100
From: Jan Bartel <janb@mortbay.com>
Reply-To: janb@mortbay.com
Organization: Mort Bay Consulting
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.5) Gecko/20031107 Debian/1.5-3
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: [security] Authentication mechanism
References: <FF7CE36846E01B439945B55FFB1DF5BEF674@customer.panix.com>
In-Reply-To: <FF7CE36846E01B439945B55FFB1DF5BEF674@customer.panix.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Alan,

If it is the intention that the Subject is populated with a Principal 
for each role (aka group) obtained from the LoginModule/SecurityRealm at 
login time, then I can see how this will work. What is confusing is that 
this doesn't seem to be implemented in the code so far (at least I 
couldn't see where the roles were populated into the Subject in the SQL 
and FileProperties LoginModules).

Do you really think it is essential to have a principal<->role mapping 
in the geronimo-web.xml? Could it be possible to just create a Principal 
for each of the security-role-ref/role-link and security-role/role-names 
  to which the WebRoleRefPermissions are assigned?


cheers,
Jan
PS Just one more slight confusion - the SecurityRealms have methods 
getUserPrincipals() and getGroupPrincipals() that actually return 
collections of Strings not Principals - do you think maybe they should 
be renamed to getUserPrincipalNames() and getGroupPrincipalNames() instead?


> Isn't that what group principals are for?
>  
>  
> Regards,
> Alan
> 
> 	-----Original Message----- 
> 	From: Jan Bartel 
> 	Sent: Fri 11/28/2003 3:45 PM 
> 	To: Alan D. Cabrera 
> 	Cc: geronimo-dev@incubator.apache.org 
> 	Subject: Re: [security] Authentication mechanism
> 	
> 	
> 
> 	Alan,
> 	
> 	There's two points I'd like to raise about the proposed
> mechanism.
> 	
> 	I think this mechanism is not dynamic enough. In the real world,
> users
> 	are dynamically granted and revoked roles at runtime. With the
> proposed
> 	mechanism I can't see any way to accomodate that - the whole
> webapp
> 	would have to be stopped and restarted if just one user was
> granted a
> 	role on the fly and wanted to exercise it.
> 	
> 	Also, it is impractical to fully enumerate all of the principals
> and
> 	their role mappings in a deployment descriptor - many
> applications in
> 	the corporate world contain thousands of users with many
> different roles
> 	each.
> 	
> 	The information about users and their roles is maintained by the
> 	Security Realm. We just need a mechanism whereby when the user
> is
> 	authenticated, we are able to pull out their roles from the
> Security
> 	Realm, convert them into Permissions and associate them with the
> 	Subject. I'll have a bit more of a think and see if I can come
> up with a
> 	firm mechanism proposal.
> 	
> 	cheers,
> 	Jan
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	Alan D. Cabrera wrote:
> 	> The Geronimo deployment descriptor will have an additional
> security
> 	> statement:
> 	> 
> 	> 3) a mapping of principals to roles.
> 	> 
> 	> So when the commit statement occurs, WebRoleRefPermission
> (servletname,
> 	> role), will be added to a principal's Permissions collection.
> When a
> 	> servlet calls the method isUserInRole(role) on a HttpRequest,
> the
> 	> ContextManager will grab the current Ssubject's context and do
> a
> 	> permission check; remember that this context was created, and
> registered
> 	> in the Geronimo login wrapper, using that Subject and so, its
> registered
> 	> ProtectionDomain contains the set of Principals that belong to
> that
> 	> Subject.  I think you know what happens after that, a call
> through the
> 	> Java security architecture which calls the implies() of the
> registered
> 	> Policy, which gets the registered Policy configuration, which
> checks the
> 	> permission.
> 	> 
> 	> 
> 	> Regards,
> 	> Alan
> 	>
> 	>       -----Original Message-----
> 	>       From: Jan Bartel
> 	>       Sent: Thu 11/27/2003 3:30 PM
> 	>       To: geronimo-dev@incubator.apache.org
> 	>       Cc:
> 	>       Subject: Re: [security] Authentication mechanism
> 	>      
> 	>      
> 	>
> 	>       Hi Alan,
> 	>      
> 	>       The web.xml file contains security statements that
> 	>       1) define some role name mappings (role-name/role-link)
> 	>       2) define which roles are permitted to access resources
> 	>      
> 	>       These then get translated into Permissions by the
> 	>       PolicyConfigurationWeb.commit() when the web.xml is
> deployed.
> 	>       Fine so far.
> 	>      
> 	>       Now, when a servlet calls the method isUserInRole(role)
> on a
> 	> HttpRequest
> 	>       we need to determine whether the call is executing on
> behalf of
> 	> an
> 	>       (authenticated) user who is able to act in the role
> specified.
> 	> Pre-JACC,
> 	>       this has been accomplished by matching the role argument
> against
> 	> the set
> 	>       of roles associated with the user which were retrieved
> by the
> 	>       LoginModule when the user logged in.
> 	>      
> 	>       With JACC, it looks like the impl of the isUserInRole
> (role) has
> 	> to
> 	>       concoct a WebRoleRefPermission (servletname, role) and
> for the
> 	> security
> 	>       infrastructure to check if that permission has been
> granted to
> 	> the user
> 	>       (Subject). So, how does the security infrastructure
> perform that
> 	> check?
> 	>       How does it determine if user X can act in the role Y?
> Doesn't
> 	> it
> 	>       require some piece of code to convert a user's roles
> into
> 	>       WebRoleRefPermissions and associate them with the user's
> 	> Subject?
> 	>      
> 	>       Hope that clarifies my confusion a bit :-)
> 	>      
> 	>       thanks
> 	>       Jan
> 	>      
> 	>       Alan D. Cabrera wrote:
> 	>       > All the roles and permissions are in the web.xml.
> What do you
> 	> mean by
> 	>       > the dynamic
> 	>       > granting of roles to users?
> 	>       >
> 	>       >
> 	>       > Regards,
> 	>       > Alan
> 	>       >
> 	>       >       -----Original Message-----
> 	>       >       From: Jan Bartel
> 	>       >       Sent: Thu 11/27/2003 3:51 AM
> 	>       >       To: geronimo-dev@incubator.apache.org
> 	>       >       Cc:
> 	>       >       Subject: Re: [security] Authentication mechanism
> 	>       >     
> 	>       >     
> 	>       >
> 	>       >       Just to add to my list of questions ...
> 	>       >     
> 	>       >       How does the current mechanism implemented in
> 	>       >       o.a.g.security.PolicyConfigurationWeb.commit()
> cope with
> 	> the
> 	>       > dynamic
> 	>       >       granting of roles to users? Looks like it is all
> set in
> 	> concrete
> 	>       > at the
> 	>       >       time of the commit(), or are the roles and
> permissions
> 	> concerned
> 	>       > those
> 	>       >       described in the web.xml?
> 	>       >     
> 	>       >       thanks again
> 	>       >       Jan
> 	>       >     
> 	>       >     
> 	>       >     
> 	>       >       Jan Bartel wrote:
> 	>       >       > I'm just taking a look at integrating the web
> tier
> 	> security
> 	>       > with
> 	>       >       > Geronimo security. I've got a couple of
> questions:
> 	>       >       >
> 	>       >       > 1.  When/who should call setMBeanServer on the
> 	>       >       >     GeronimoLoginConfiguration? Should I call
> it
> 	>       >       >     just before doing a LoginContext login()
> call?
> 	>       >       >
> 	>       >       >
> 	>       >       > 2.  What code is responsible for configuring
> the
> 	> SecurityRealm
> 	>       >       >     instances? Should they be configurable
> from the
> 	>       >       >     security-service.xml file?
> 	>       >       >
> 	>       >       > 3.  I still can't work out where the mapping
> of the
> 	> user's
> 	>       > roles
> 	>       >       >     that are retrieved by the SecurityRealm
> are turned
> 	> into
> 	>       > permissions
> 	>       >       >     suitable for a HttpRequest.isUserInRole()
> call
> 	> impl?
> 	>       >       >
> 	>       >       > Any pointers on any of these would be welcome.
> 	>       >       >
> 	>       >       > thanks
> 	>       >       > Jan
> 	>       >     
> 	>       >     
> 	>       >     
> 	>       >
> 	>      
> 	>      
> 	>      
> 	>
> 	
> 	
> 	
>