[Pki-users] confused about access control list

Wed May 6 01:51:48 UTC 2015

Hi,

I did not know you were using the REST interface.  I actually have not 
used the REST interface pki commands much but I can try to reproduce and 
investigate if you could give me the  following info:
1. what exact ACL did you change and how you changed it?
2. What command did you use (how exactly did you use it) that resulted 
in the log?  As I'm really not familiar with these new cli's it would 
help speed up if you could provide as much detail as possible.

Regardless of the interface, the profile framework actually allows one 
to specify *per profile* authentication and authorization.  you can look 
in any existing profile and see the following parameters and values.
auth.instance_id
authz.acl

Christina

On 05/02/2015 11:34 AM, Ali Khalidi wrote:
> Thanks for taking the time to look at this.
>
> Since I was using the pkiconsole, I actually had two separate entries:
> one for all uses (default), and one to deny that particular user,
> thinking that they will be evaluated together, with deny rules have
> precedence over allow rules. apparently, I was wrong, please confirm.
>
> I've modified the rule to the one you mentioned, but unfortunately it
> did not accomplish the required result, as well.
>
> looking into the debug log, I noticed that profile based enrollment
> does not get mapped to a specific Authentication or Authorization. so,
> no matter what ACL I put it will not have any effect. moreover, since
> the mapping does not exists, even the confi files: acl.properties or
> auth-method.properties have no effect as well.
>
> The last line in the log (preceded by a line of dashes) is somehow
> confusing, and I was wondering how would you ACL caProfileSubmit
> through LDAP? isn't the resourceACL LDAP as well?!
>
> reference is this REST mapping:
> https://git.fedorahosted.org/cgit/pki.git/plain/base/common/src/com/netscape/certsrv/cert/CertRequestResource.java
>
> now, the debug log:
>
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> AccountResource.login()
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> mapping: account
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> loading /usr/share/pki/ca/conf/auth-method.properties
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> checking /var/lib/pki/cse-ca/ca/conf/auth-method.properties
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> required auth methods: [passwdUserDBAuthMgr, certUserDBAuthMgr]
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> authentication manager: certUserDBAuthMgr
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor:
> access granted
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor:
> AccountResource.login()
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: mapping:
> account.login
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: principal: caagent
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: loading
> /usr/share/pki/ca/conf/acl.properties
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: checking
> /var/lib/pki/cse-ca/ca/conf/acl.properties
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: ACL:
> certServer.ca.account,login
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: checkACLS(): ACLEntry
> expressions= user="anybody"
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluating expressions:
> user="anybody"
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluated expression:
> user="anybody" to be true
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: DirAclAuthz: authorization passed
> [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: access granted
> ****BEGIN SEGMENT OF INTEREST****
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor:
> CertRequestResource.enrollCert()
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor:
> mapping: default
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor:
> required auth methods: [*]
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor:
> authentication manager: certUserDBAuthMgr
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor:
> access granted
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor:
> CertRequestResource.enrollCert()
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: No ACL mapping.
> -----------------------------------------------------------------------------------------------------------------------------------------------
> [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: according to ccMode,
> authorization for servlet: caProfileSubmit is LDAP based, not XML {1},
> use default authz mgr: {2}.
> ****END SEGMENT OF INTEREST****
>
> thanks,
>
>
> On Wed, Apr 29, 2015 at 7:59 PM, Christina Fu <cfu at redhat.com> wrote:
>> Hi,
>> I was looking for an exact aci syntax example you tried that failed so I
>> could help you better with.
>> Did you do something like:
>> resourceACLS: certServer.ee.request.enrollment:submit:allow (submit)
>> user!="someBody" && group="Agents":All Agents other than someBody may submit
>> an enrollment request
>>
>> I got the syntax info from the link I gave you.  Let me know if that's what
>> you tried.
>>
>> Christina
>>
>>
>> On 04/24/2015 11:14 AM, Ali Khalidi wrote:
>>
>> In my test, I've added an user to CM and assigned him Agent group
>> permissions.
>> now, I want to deny this user enrollment submission, so there are two
>> default and pre-existing ACLs of relevance:
>> certServer.ca.request.enrollment and certServer.ee.request.enrollment
>> in both I tried the following to the submit right:
>> change the submit right from allow to deny -> the user can still submit and
>> enroll a certificate
>> change back to allow, then added a deny rule with the username specified ->
>> the user can still submit and enroll a certificate
>>
>> these were just experiments to understand how ACLs work.
>>
>> my end goal, if possible with dogtag, and I would appreciate if you point me
>> to the right direction is:
>> restrict an agent to submit and execute and enrollment based on a specific
>> certificate profile.
>>
>> having said the latter, the user_origreq looked promising for that matter,
>> but I have no clue how to create a new ACL with it. help is appreciated in
>> the area as well.
>>
>>
>> Thanks,
>>
>> Ali
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 24, 2015 at 7:31 PM, Christina Fu <cfu at redhat.com> wrote:
>>>
>>> On 04/22/2015 02:17 AM, Ali Khalidi wrote:
>>>
>>> I've tried a simple example of using the ACL to block profile listing and
>>> it works. however, I want to disable a CA agent from submitting/approving or
>>> executing any enrollment requests. I've went through all the ACLs, and
>>> whenever I encountered a submit right, I flipped to deny. despite that the
>>> agent still is able to submit and enroll certificates.
>>>
>>> information on access control can be found here:
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authorization_for_CRTS_Users.html
>>>
>>> It would help if you give us an acl example that you tried that does not
>>> work?
>>>
>>>
>>> another aspect, I was looking into the user_orgreq ACL plugin. can someone
>>> provide and an example on how this can be used in the context of ACLs?
>>>
>>>
>>> The user_origreq is an access evaluator plugin for the
>>> UserOrigReqAccessEvaluator.  Its primary purpose is for access control
>>> during renewal.  It checks to see the the authenticated user and the
>>> original request ownership match.
>>>
>>> Hope this helps.
>>>
>>>
>>> thanks,
>>>
>>>
>>> _______________________________________________
>>> Pki-users mailing list
>>> Pki-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>
>>>
>>>
>>> _______________________________________________
>>> Pki-users mailing list
>>> Pki-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-users
>>
>>