|
From: Michael S. <mi...@st...> - 2014-11-07 09:46:47
|
HI! (using 6.2) I'd like to delegated control (approval, revocation, etc.) for some specific EE profiles of sub CAs to groups of RA admins. Therefore I've created a special sub CA for issuing RA admin certs, let's call it "CA_RA-Admins" and a EE profile "EE_RA-Admin". After that a administrator role was created and certs issued based on "EE_RA-Admin" were added. Access rules were defined granting rights for "Other-Sub-CA" with EE profile "EE_Others". But it does not work. I have to grant rights to "CA_RA-Admins" and the EE profile "EE_RA-Admin" to make it work. But obviously that's not right. Even when issuing certs based EE profile "EE_RA-Admin" with "Other-Sub-CA" it does not work. How do others delegate control to certain administrator roles? Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2014-11-11 08:52:45
|
One important thing in profiles are how "available CAs" and "available profiles" are selected. An administrator does not have access to a profile if he/she does not have access to all selected "available" CAs and profiles. Cheers, Tomas ********** PrimeKey Solutions AB Anderstorpsvägen 16, 171 54 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI ********** On 2014-11-07 10:46, Michael Ströder wrote: > HI! > > (using 6.2) > > I'd like to delegated control (approval, revocation, etc.) for some specific EE > profiles of sub CAs to groups of RA admins. > > Therefore I've created a special sub CA for issuing RA admin certs, let's call > it "CA_RA-Admins" and a EE profile "EE_RA-Admin". > > After that a administrator role was created and certs issued based on > "EE_RA-Admin" were added. > > Access rules were defined granting rights for "Other-Sub-CA" with EE profile > "EE_Others". > > But it does not work. I have to grant rights to "CA_RA-Admins" and the EE > profile "EE_RA-Admin" to make it work. But obviously that's not right. > > Even when issuing certs based EE profile "EE_RA-Admin" with "Other-Sub-CA" it > does not work. > > How do others delegate control to certain administrator roles? > > Ciao, Michael. > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Michael S. <mi...@st...> - 2014-11-11 08:52:58
Attachments:
smime.p7s
|
Michael Ströder wrote: > (using 6.2) > > I'd like to delegated control (approval, revocation, etc.) for some specific EE > profiles of sub CAs to groups of RA admins. I have it somewhat working with detailed access rights for EE profiles "EEP_Admin" and "EEP_Server" (see details below). Mainly "EEP_Admin/view_end_entity ACCEPT" is the solution. Is this the officially supported way to do it? BTW: Why does it take two minutes to list the access rights for a single role? Ciao, Michael. # /opt/ejbca/bin/ejbca.sh roles listrules ROLE_ServerApprovers No database integrity protection available in this version of EJBCA. /administrator ACCEPT /ca/CA_Test-Server-CA-1-2014-10 ACCEPT /ca/CA_Test-Admin-CA-1-2014-10 ACCEPT /ca_functionality/create_certificate ACCEPT /ca_functionality/store_certificate ACCEPT /ca_functionality/view_certificate ACCEPT /endentityprofilesrules/EEP_Server/approve_end_entity ACCEPT /endentityprofilesrules/EEP_Server/create_end_entity ACCEPT /endentityprofilesrules/EEP_Server/delete_end_entity DECLINE /endentityprofilesrules/EEP_Server/edit_end_entity ACCEPT /endentityprofilesrules/EEP_Server/revoke_end_entity ACCEPT /endentityprofilesrules/EEP_Server/view_end_entity ACCEPT /endentityprofilesrules/EEP_Server/view_end_entity_history ACCEPT /endentityprofilesrules/EEP_Admin/approve_end_entity DECLINE /endentityprofilesrules/EEP_Admin/create_end_entity DECLINE /endentityprofilesrules/EEP_Admin/delete_end_entity DECLINE /endentityprofilesrules/EEP_Admin/edit_end_entity DECLINE /endentityprofilesrules/EEP_Admin/revoke_end_entity DECLINE /endentityprofilesrules/EEP_Admin/view_end_entity ACCEPT /endentityprofilesrules/EEP_Admin/view_end_entity_history DECLINE /ra_functionality/approve_end_entity ACCEPT /ra_functionality/create_end_entity ACCEPT /ra_functionality/edit_end_entity ACCEPT /ra_functionality/revoke_end_entity ACCEPT /ra_functionality/view_end_entity ACCEPT /ra_functionality/view_end_entity_history ACCEPT |
|
From: Tomas G. <to...@pr...> - 2014-11-11 08:59:29
|
On 2014-11-11 09:52, Michael Ströder wrote: > Michael Ströder wrote: >> (using 6.2) >> >> I'd like to delegated control (approval, revocation, etc.) for some specific EE >> profiles of sub CAs to groups of RA admins. > > I have it somewhat working with detailed access rights for EE profiles > "EEP_Admin" and "EEP_Server" (see details below). Mainly > "EEP_Admin/view_end_entity ACCEPT" is the solution. > > Is this the officially supported way to do it? > > BTW: > Why does it take two minutes to list the access rights for a single role? Hmm, not for me...goes in a jiffy... > > Ciao, Michael. > > # /opt/ejbca/bin/ejbca.sh roles listrules ROLE_ServerApprovers > No database integrity protection available in this version of EJBCA. > /administrator ACCEPT > /ca/CA_Test-Server-CA-1-2014-10 ACCEPT > /ca/CA_Test-Admin-CA-1-2014-10 ACCEPT > /ca_functionality/create_certificate ACCEPT > /ca_functionality/store_certificate ACCEPT > /ca_functionality/view_certificate ACCEPT > /endentityprofilesrules/EEP_Server/approve_end_entity ACCEPT > /endentityprofilesrules/EEP_Server/create_end_entity ACCEPT > /endentityprofilesrules/EEP_Server/delete_end_entity DECLINE > /endentityprofilesrules/EEP_Server/edit_end_entity ACCEPT > /endentityprofilesrules/EEP_Server/revoke_end_entity ACCEPT > /endentityprofilesrules/EEP_Server/view_end_entity ACCEPT > /endentityprofilesrules/EEP_Server/view_end_entity_history ACCEPT > /endentityprofilesrules/EEP_Admin/approve_end_entity DECLINE > /endentityprofilesrules/EEP_Admin/create_end_entity DECLINE > /endentityprofilesrules/EEP_Admin/delete_end_entity DECLINE > /endentityprofilesrules/EEP_Admin/edit_end_entity DECLINE > /endentityprofilesrules/EEP_Admin/revoke_end_entity DECLINE > /endentityprofilesrules/EEP_Admin/view_end_entity ACCEPT > /endentityprofilesrules/EEP_Admin/view_end_entity_history DECLINE > /ra_functionality/approve_end_entity ACCEPT > /ra_functionality/create_end_entity ACCEPT > /ra_functionality/edit_end_entity ACCEPT > /ra_functionality/revoke_end_entity ACCEPT > /ra_functionality/view_end_entity ACCEPT > /ra_functionality/view_end_entity_history ACCEPT > > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Michael S. <mi...@st...> - 2014-11-11 09:00:16
Attachments:
smime.p7s
|
Tomas Gustavsson wrote: > One important thing in profiles are how "available CAs" and "available > profiles" are selected. An administrator does not have access to a > profile if he/she does not have access to all selected "available" CAs > and profiles. Now the interesting question is what "have access" really means (see my own follow-up). Obviously the RA admin of another sub CA should not be able to let the admin CA issue arbitrary certs. Ciao, Michael. |
|
From: Tomas G. <to...@pr...> - 2014-11-11 12:04:39
|
An ra admin can issue certificates for the CAs and profiles he have access to, not others. "Michael Ströder" <mi...@st...> skrev: (11 november 2014 10:00:01 CET) >Tomas Gustavsson wrote: >> One important thing in profiles are how "available CAs" and >"available >> profiles" are selected. An administrator does not have access to a >> profile if he/she does not have access to all selected "available" >CAs >> and profiles. > >Now the interesting question is what "have access" really means (see my >own >follow-up). Obviously the RA admin of another sub CA should not be able >to let >the admin CA issue arbitrary certs. > >Ciao, Michael. > > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >Comprehensive Server Monitoring with Site24x7. >Monitor 10 servers for $9/Month. >Get alerted through email, SMS, voice calls or mobile push >notifications. >Take corrective actions from your mobile device. >http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > >------------------------------------------------------------------------ > >_______________________________________________ >Ejbca-develop mailing list >Ejb...@li... >https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Michael S. <mi...@st...> - 2014-11-12 13:46:33
Attachments:
smime.p7s
|
Tomas Gustavsson wrote: > An ra admin can issue certificates for the CAs and profiles he have access to, not others. Sorry for nitpicking here: The problem is that if CAs and/or end entity profiles of the RA admin's cert and the new cert differ you have to give at least view rights to the RA admin's CA and EE profile. Ciao, Michael. |