Role-based access control (RBAC) system of OpenCA is too strict

[Arsen Hayrapetyan]

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:

=============================================================
      <permission>
        <module>(0|@pub_module_id@)</module>
        <role>.*</role>
        <operation>csr new</operation>
        <owner>.*</owner>
      </permission>

      <permission>
        <module>(0|@pub_module_id@)</module>
        <role>User</role>
        <operation>csr new for hosts or services</operation>
        <owner>.*</owner>
      </permission>
=============================================================

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

======================
<login>
<type> none </type>
</login>
======================

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@...
https://lists.sourceforge.net/lists/listinfo/openca-users

[RogerImpey]

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 [e-mail] https://lists.sourceforge.net/lists/listinfo/openca-users

[Massimiliano Pala-3]

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@...
>     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@...
> https://lists.sourceforge.net/lists/listinfo/openca-users

--

Best Regards,

        Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   openca@...
                                                  project.manager@...

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--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@...
https://lists.sourceforge.net/lists/listinfo/openca-users

[RogerImpey]

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 [e-mail]
>     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
> [e-mail]
> https://lists.sourceforge.net/lists/listinfo/openca-users


--

Best Regards,

        Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/openca-users

[Massimiliano Pala-3]

Hi Roger,

So.. tell me more about what you want to do. How you want to restrict the
request for an host certificate ? Based on what ? A user certificate or
what ?

Later,
Max



On 08/19/2010 03:24 PM, RogerImpey wrote:

>
> 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.

--

Best Regards,

        Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   openca@...
                                                  project.manager@...

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--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@...
https://lists.sourceforge.net/lists/listinfo/openca-users

[RogerImpey]

Hi;

Yes, for requesting host/service certificates and for requesting re-keying of user certificates, I wish to have the requests authenticated with the requestor's own user certificate.

     Roger
 

Massimiliano Pala-3 wrote:

Hi Roger,

So.. tell me more about what you want to do. How you want to restrict the
request for an host certificate ? Based on what ? A user certificate or
what ?

Later,
Max



On 08/19/2010 03:24 PM, RogerImpey wrote:
>
> 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.


--

Best Regards,

        Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/openca-users

[Massimiliano Pala-3]

Hi Roger,

I think the easiest way would be to:
- enable the SSL (with client optional in Apache)
- add a check in the certificate request command that check for the
   existence of the env variable where the client certificate is
   (be sure to enable only your CA's certificate as a valid CA for
    client auth in Apache).

Let me know if you need help with that..

Ciao,
Max


On 08/19/2010 03:37 PM, RogerImpey wrote:
>
> Hi;
>
> Yes, for requesting host/service certificates and for requesting re-keying
> of user certificates, I wish to have the requests authenticated with the
> requestor's own user certificate.
>
>       Roger


--

Best Regards,

        Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   openca@...
                                                  project.manager@...

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--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@...
https://lists.sourceforge.net/lists/listinfo/openca-users