Hi:
Thanks for the rapid reply.
Is there another way to do the same thing? That is, provide some form of
authentication for the requests for host/service certificates, while keeping
the request of user certificates open.
Or maybe I am thinking about it all wrong, and there are completely
different (better?) ways of doing the same thing.
Roger
Massimiliano Pala-3 wrote:
>
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
View this message in context:
http://old.nabble.com/Role-based-access-control-%28RBAC%29-system-of-OpenCA-is-too-strict-tp12642086p29485612.html
Sent from the openca-users mailing list archive 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
