[Pki-users] confused about access control list

Sat May 2 18:34:59 UTC 2015

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