1. Argus: General Introduction
Christoph Witzig, SWITCH

2. Outline Introduction Installation and Configuration
Command line interface
Summary
ROD Workshop June 2, 2010, Amsterdam

3. Introduction Argus = gLite Authorization Service In EMI: Argus PT
Developed in EGEE-III
Passed staged rollout in April 2010
In EMI: Argus PT
Responsible for maintenance and support
Institutions: CNAF, HIP, NIKHEF, SWITCH
Argus = Attribute-based Authorization service
Attributes = DN, CA, FQAN, ….
Internal engine that determines whether a request containing a set of attributes shall be authorized or not
Note abbreviation: authZ = authorization
ROD Workshop June 2, 2010, Amsterdam

4. Supported Use-Cases (1/2)
glExec on WN (multi-user pilot job)
ROD Workshop June 2, 2010, Amsterdam

5. Supported Use-Cases (2/2)
Global Banning list
OSCT / EGI CSIRT operates a global banning list (for incidents)
Argus can be configured to import this global banning list
Note:
Global banning is by default disabled
Global banning (if activated) can be overruled by local admin
gridFTP (GSI call out)
CREAM (see next slide)
Integration Argus – CREAM currently in development
Other services are planned in EMI  single point for authorization decisions at a site
ROD Workshop June 2, 2010, Amsterdam

6. On the CE
ROD Workshop June 2, 2010, Amsterdam

7. Service Components
Initial rules:
Banning unbanning
Pilot job
Initial default deployment:
All components on one host
Administration Point: Formulating the rules through command line interface and/or
file-based input
Decision Point: Evaluating a request from a client based on the rules
Enforcement Point: Thin client part and server part: all complexity in server part
Runtime Execution Environment: Under which env. must I run? (UID, GID)
ROD Workshop June 2, 2010, Amsterdam

8. Installation and Configuration
Introduction
Installation and Configuration
Command line interface
Summary
ROD Workshop June 2, 2010, Amsterdam

9. Installation YAIM Installation: Manual installation:
Installation and configuration of Argus on one host (default configuration) using YAIM
Check out functionality using CLI
Add policies
Reconfigure glexec (resp. LCMAPS) on WN to call out to Argus
Enable global banning list (if desired)
Manual installation:
Install three components (PAP, PDP, PEP daemon)
Configure components
Including administrator access configuration
Check out functionality using CLI
Reconfigure glexec
ROD Workshop June 2, 2010, Amsterdam

10. Configuring Administrator Access (1/2)
YAIM enables access for administrator
YAIM Variable PAP_ADMIN_DN in site-info.def
Listing ACLs of Argus: ~]$ pap-admin list-acl "/DC=ch/DC=switch/DC=slcs/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=Christoph Witzig 8CA3021D" :
POLICY_READ_LOCAL|POLICY_READ_REMOTE|POLICY_WRITE|CONFIGURATION_READ|CONFIGURATION_WRITE
Note:
passphrase for private key will have to be entered
Every command supports –h option
ROD Workshop June 2, 2010, Amsterdam

11. Configuring Administrator Access (2/2)
Adding a DN or FQAN to gain full access:
1. Add a DN:
~]$ pap-admin add-ace ‘/DC=ch/DC=switch/DC=slcs/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=Christoph Witzig 8CA3021D' 'ALL’
2. Add an FQAN
~]$ pap-admin add-ace '/atlas/Role=VO-Admin’ 'ALL’
3. Remove an FQAN
ROD Workshop June 2, 2010, Amsterdam

12. Configuring User Mapping
grid-mapfile and groupmapfile determines the user mapping to username and groupname(s)
Same format as LCMAPS, same functionality
Are configured through the mandatory YAIM variables
USERS_CONF
GROUPS_CONF
Note: If manual configuration, then these directories and files have to be created manually
ROD Workshop June 2, 2010, Amsterdam

13. Monitoring Argus
Nagios plug-ins are available
ROD Workshop June 2, 2010, Amsterdam

14. Command line interface
Outline
Introduction
Installation and Configuration
Command line interface
Summary
ROD Workshop June 2, 2010, Amsterdam

15. Argus CLI Argus is operated from the command line (YAIM installed)
Starting / stopping / query status of the service components
Three components PAP, PDP, PEPd
/etc/init.d/<component> <start><stop><status>
Configure admin access rights
Add/remove policies
Policies either
Added/removed from command line
Import/export of file in simplified policy language
Keep in mind: Initial use-case simply uses site global banning/unbanning of DNs, FQANs, VOs, CAs
ROD Workshop June 2, 2010, Amsterdam

16. Banning Users
To ban a user on the entire site: pap-admin ban subject <dn> pap-admin ban fqan <fqan>
To un-ban a user on the entire site: pap-admin un-ban subject <dn> pap-admin un-ban fqan <fqan>
To ban a user on a specific resource: pap-admin ban -r resource_id –a action subject <dn>
ROD Workshop June 2, 2010, Amsterdam

17. Authorization Decisions (1/3)
Decisions are taken for a given resource and a given action:
E.g. A WN has a resource id and the action may be “execute_pilot”
Policies are formulated for
Individual resource and action
Groups of resources and groups of action
All resources and all actions
Examples:
Site global enable/disable of a VO:
For all resources and actions permit all users of a given VO
Deny a user on all WNs for glexec
For all WN resources and all actions deny user DN
Permit VOs only on certain CEs
For resource “CE_1” permit VO “ATLAS”
For resource “CE_2” permit VO “CMS”
ROD Workshop June 2, 2010, Amsterdam

18. Authorization Decisions (2/3)
Simplified Policy Language (SPL)
Allows to create more complex policies using a custom syntax
Policies are loaded into Argus through CLI
Example:
~]$ more test_policy.txt
resource ".*" {
obligation " { }
action ".*" {
rule permit {vo="atlas"}
rule permit {vo="cms"} }
pap-admin add-policies-from-file test_policy.txt
ROD Workshop June 2, 2010, Amsterdam

19. Authorization Decisions (2/3)
List policies:
~]$ pap-admin list-policies
Please enter the passphrase for the private key file /home/witzig/.globus/userkey.pem:
default (local):
resource ".*" {
obligation " { }
action ".*" {
rule permit { vo="atlas" }
rule permit { vo="cms" }
ROD Workshop June 2, 2010, Amsterdam

20. Ordering of Policies
Note: ordering matters: First applicable rule determines the result
~]$ pap-admin list-policies
default (local):
resource ".*" {
obligation { }
action ".*" {
rule deny { subject="CN=Christoph Witzig 8CA3021D,O=Switch - Teleinformatikdienste fuer Lehre und Forschung,DC=slcs,DC=switch,DC=ch" }
rule permit { vo="atlas" }
rule permit { vo="cms" } }
ROD Workshop June 2, 2010, Amsterdam

21. Testing Argus Setup (1/2)
Configure glExec on WN to call-out to Argus
Example test on WN: # pilot job proxy export X509_USER_PROXY=${X509_USER_PROXY:-"/tmp/x509up_`id -u`"}
# payload job proxy export GLEXEC_CLIENT_CERT=${GLEXEC_CLIENT_CERT:-$X509_USER_PROXY} /opt/glite/sbin/glexec /usr/bin/id; echo $? uid=40205(testuseraccount) gid=2013(testusergroup) 0
ROD Workshop June 2, 2010, Amsterdam

22. Testing Argus Setup (2/2)
A simple standalone client is also available: pepcli Needs to be installed separately – tool for testing/debugging only
Policy: pap-admin ap --resource ".*" --action ".*" permit vo="switch”
Test: pepcli -p -r my_res -a my_action \ -c /tmp/x509up_u cert .globus/usercert.pem \ --key .globus/userkey.pem
Resource: my_res
Decision: Permit
Obligation: (caller should resolve POSIX account mapping)
Username: dteam026
Group: dteam
ROD Workshop June 2, 2010, Amsterdam

23. Note
Argus updates the policies in regular intervals and caches results for performance reasons
Consequence: when modifying policies you must execute the following two commands to make sure they are valid immediately:
# policy is effective immediately /etc/init.d/pdp reloadpolicy
# clear cache
/etc/init.d/pepd clearcache
ROD Workshop June 2, 2010, Amsterdam

24. Support Mailing list: argus-support@cern.ch Argus support unit in GGUS
Wiki:
ROD Workshop June 2, 2010, Amsterdam

25. Further Information
About Argus:
authZ service design document:
Deployment plan:
General EGEE grid security:
Authorization study:
gLite security: architecture:
ROD Workshop June 2, 2010, Amsterdam

26. Motivation for Argus Appendix Appendix
ROD Workshop June 2, 2010, Amsterdam

27. Motivation: Which Problems Are We Trying to Solve?
Different Services use different authorization mechanisms
Some services even use internally more than one authorization framework
Site administrators do not have simple debugging tools to check and understand their authorization configuration
Site administrators must configure the authorization for each service at their site separately
Consequence 1: At a site, there is no single point to ban users/groups of users for the entire site
Consequence 2: many site administrators don’t know how to ban users
There should be a command line tool for banning and un-banning users at a site
ROD Workshop June 2, 2010, Amsterdam

28. Motivation: Which Problems Are We Trying to Solve?
There is no central grid-wide banning list to be used during incidents
Consequence: Urgent ban cannot be taken for granted during incidents
Sites cannot publish their complete authorization policy to the outside world
Currently only assignment of FQANS (experience of DENY tags)
Note: Fixing this problem does not mean that sites MUST publish their authorization policy
No monitoring on authorization decisions
ROD Workshop June 2, 2010, Amsterdam

29. Motivation: Benefits of the Authorization Service (1/2)
Main benefit within EGEE-III:
Addressing the above list of short-comings
In addition:
Resistance to failure and simple means for scaling the service
Flexible deployment model
No dependency on a shared file system
High availability option
Client component is very lightweight
Small amount of code
Few dependencies (especially on WN)
Portability: support on other OS and languages easy
ROD Workshop June 2, 2010, Amsterdam

30. Motivation: Benefits of the Authorization Service (2/2)
In addition (cont.):
Enables/eases various authorization tasks:
Banning of users (VO, WMS, site, or grid wide)
Composition of policies – CERN policy + experiment policy + CE policy + OCST policy + NGI policy=> Effective policy
Support for authorization based on more detailed information about the job, action, and execution environment
Support for authorization based on attributes other than FQAN
Support for multiple credential formats (not just X.509)
Support for multiple types of execution environments
Virtual machines, workspaces, …
Nagios plug-ins provided for monitoring of service
ROD Workshop June 2, 2010, Amsterdam