1:34 p.m.
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/netsc...
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(a)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(a)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/...
>
> 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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users
>
>
>
> _______________________________________________
> Pki-users mailing list
> Pki-users(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users