Hello Roger, unfortunately I have to say that the issue has not been addressed. This is for many reasons, actually.
Because of the problems exposed here, I decided to provide a more fine-grained access support with the next releases of OpenCA. The problem I am facing at the moment is the lack of spare time to dedicate to the project (strangely enough, we do not have any supporters at the moment.. so, it is all voluntary work!). The idea is to have a per-user *and* per-role fine-grained access control system that is accessible from within the single commands to allow the type of operations listed in this email. Because of this, there are several new commands that need to be added to the RA/CA interfaces that will allow for users management. This is a lot of work, unfortunately. Don't expect the solution to be ready soon, there's a lot of "meat" on the fire at the moment and not many resources available.. of course, if there are some people who would like to volunteer... :D Cheers, Max On 08/19/2010 02:32 PM, RogerImpey wrote:
Hi: Was this post's question answered? I have exactly the same problem.
Is there a good way around? Roger
Arsen Hayrapetyan wrote:
Hi all (especially developers), Long ago I posted a question about
restriction of access to parts of the openca interfaces. There was
no solution to it. I am trying to do this with RBAC, but the system
is too rigid. The problem is following. I have two web-pages on my
openca Public interface: 1) Page for users to request certificates
2) Page for administrators to request certificates for their hosts
The first page is of public access, everybody can send a request for
user certificate. However, the second page should be available to
those users only (administrators), who posess valid user certificate
from my CA. This is a common practice: to oblige host certificate
requesters to have already the certificate from the given CA. I
tried to use OpenCA RBAC mechanism to restrict access to the second
page. For that I added a separate command HostCSR(basically the copy
of basic_csr script for CSR generation) and modified
rbac/acl.xml.template file to have the following:
=============================================================
(0|@pub_module_id@) .* csr new .* (0|@pub_module_id@) User csr new
for hosts or services .*
============================================================= As one
can see everybody (regardless of the role assigned to their
certificate/login name) is allowed to execute basic_csr script
(first part), and only those with 'User' role are allowd ro execute
the HostCSR (second part). Now when I log in with my User
certificate (which is issued by my CA, registered with database on
Public interface node, and has the role 'User' assigned), my
certificate IS NOT retrieved from database and the role assigned to
it IS NOT changed, because in access_control/pub.xml file which
controls the authentication method for the interface I have
====================== none ====================== Apparently, I
cannot have other authentication method because I need UNRESTRICTED
access to user certificate request page. Later when it comes to
execution of HostCSR command, the system examins the acl.xml file,
fetches the role 'User' and compares it with the role of host
certificate requester, which is EMPTY. As a result I have:
"Permission denied" error. In fact the access control is controlled
on the interface level (pub, ra, node), not at the level of
commands. This is too rigid. What developers think about making
access control more fine-grained? I would appreciate also any
solution to this problem (currently I am implementing one: getting
the DN of certificate which user uses to access the host CSR
generation page from apache, searching for it in the database, check
the role of the certificate found and granting access to the page,
if the role is 'User'. But this solution is clumsy. I would like
more light-weight one.) I am asking specially implementers of openca
RBAC system not to ignore this e-mail. Thanks, Arsen.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Openca-Users mailing
list Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
------------------------------------------------------------------------
View this message in context: Re: Role-based access control (RBAC)
system of OpenCA is too strict
<http://old.nabble.com/Role-based-access-control-%28RBAC%29-system-of-OpenCA-is-too-strict-tp12642086p29485118.html>
Sent from the openca-users mailing list archive
<http://old.nabble.com/openca-users-f3692.html> at Nabble.com.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
--
Best Regards,
Massimiliano Pala
--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] ope...@acm.org
project.mana...@openca.org
Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
-- Isaac Asimov
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Openca-Users mailing list Openca-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-users
