1 / 78

Site Access Control

Site Access Control. Grid Middleware 3 David Groep, lecture series 2005-2006. Outline. Authorisation Framework Policies, policy combination and enforcement PDP, PIP and PEP LCAS, GridSite, JavaTrustManager Credential Mapping and local policies unix domain for jobs

wesley
Download Presentation

Site Access Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Site Access Control Grid Middleware 3 David Groep, lecture series 2005-2006

  2. Grid Middleware III 2 Outline • Authorisation Framework • Policies, policy combination and enforcement • PDP, PIP and PEP • LCAS, GridSite, JavaTrustManager • Credential Mapping and local policies • unix domain for jobs • account mapping across clusters (LDAP, or NSS-JR) • workspace service and virtualisation • Policy languages • SAML and XACML • Scheduling and batch systems • getting into the mess: preserving priorities? • Network and firewall issues

  3. Grid Middleware III 3 Authorization Stakeholders, a reminder

  4. Grid Middleware III 4 Site Access Control Networkperimeter Sand-boxing user space Resource Site Proxy service Deleg.cert Credstore AA VOpolicy delegation Accesscontrol Authorization Sitepolicy ServiceContainer Proxycert Trustanchors ... Authentication Authentication Revo- cation Transport level security Logging Hostcert

  5. Grid Middleware III 5 What Problems should we solve • Fit ‘external’ users into existing infrastructure • fork jobs, batch queuing systems, disks & mass stores, … • enforce (local) security policies • e.g. a panic button, blacklisting of users • ensure that global (VO) policies are satisfied locally • in as far as possible, given local mechanisms

  6. Grid Middleware III 6 What To Do? • collect policies that need to be enforced • collect the information on which to base the decision • make the decision

  7. Grid Middleware III 7 Distinct pieces in the process flow • Authentication • Authorization • results in a yes/no decision • possibly with obligations • Service access • For legacy job execution services (Unix, Win32), need an execution environment with a system credential:Credential Mapping needed (site-local, to preserve autonomy) • For hosted servicesexecute the service request, taking into account service-specific access controls (such as ACLs for file catalogue access)

  8. Grid Middleware III 9 Context cache PEPService ormessageinterceptor decision PDP PIP PIP PDP User inblacklist? RetrieveVO info Retrievelocal info evaluate Chain 1 ... OR Chain 2 ... = PAP accessible interface Architecture for Local Access Control

  9. Grid Middleware III 10 Authorization Framework components • Policy Decision Point (PDP) • makes a binary “yes/no” decision • based on a policy, that can be nested • Policy Information Point (PIP) • extract information from sources, needed to provide the assertions for making the decision • Policies can be ‘hybrid’ • “SAML with obligations”, where the policy evaluates to Yes/No, but a Yes carries specific obligations for the PEP to enforce (such as an account mapping) • Policy Enforcement Point (PEP) • enforce the yes/no decision of a PDP

  10. Grid Middleware III 11 A ‘perfectly’ integrated model • Collect policies and assertions through PIPs • attributes pushed by the client, e.g. VOMS-enabled proxies • attributed retrieved via a pull mode (Shib-style, e.g. via WAYF) • policies that constrain usage (restricted delegation) • site-local policies • resource-local policies • Assert their authenticity and validity • incoming policies and assertions should be signed (authentic) • not expired and recognised by the deciding party (valid) • Evaluate all these policies together in a (single) PDP • Possibly, return obligations for e.g. unix system integration

  11. Grid Middleware III 12 Context cache PEPService ormessageinterceptor decision PDP PIP PIP PDP User inblacklist? RetrieveVO info Retrievelocal info evaluate Chain 1 ... OR Chain 2 ... = PAP accessible interface Issues with an integrated model • Requires harmonisation (or translation via a context cache) • Should include precedence information (site prevalence) • In practice, some ‘quick’ decision should be made earlier for performance reasons (black-listing, for instance) • today a mixture of • course-grained only (compute) • ACL based (storage) • simple binary (brokering)

  12. Grid Middleware III 13 Issues with the model (2) • AuthZ cannot always be cleanly separated from the service • Example: data access • access to the service ‘read file’ can be allowed, but access to any specific file restricted by ACLs on the file • so the AuthZ front-end should either ‘snoop’ into the service and use the ACLs • or the business logic should do the AuthZ (again) see access control to services slide later

  13. Grid Middleware III 14 Local Policy today: mapping credentials • Grid user is mapped to local identities to determine policy • At the site, policies are expressed in these local identities (like unix groups) Map tolocal name Grid Identity LocalPolicy Map tolocal name LocalPolicy graphic: Frank Siebenlist, Argonne Natl. Lab, Globus Securitywith SAML, Shibboleth and GridShib, May 2005

  14. Grid Middleware III 15 Implementations today • All separate authN and authZ • most separate mapping from authZ • where necessary, e.g. for databases and legacy execution • in most general sense, it is a handle for local policy • Faced with two worlds: Java and native (C) • Need a solution for both, but no unification yet • Examples: • C world: LCAS & LCMAPS(so this talk misses out on Prima, GUMS, gPlazma, …) • Java: GT4 Authorization Framework(so this talk misses out on Generic AAA, PERMIS, …) • papers on the others are in the bundle!

  15. Grid Middleware III 17 The C World: job submission and GridFTP • LCAS • authorization based on credentials and job information (RSL) • returns a yes/no answer • pluggable framework of PDPs, using dlopen(3) system • LCMAPS • credential mapping based on user credential and additional handle information • enforcement within the process space needed • GUMS: access based on a site-local database of grid-to-local creds • gPlazma: gid and uid assignments for ACLs on storage

  16. Grid Middleware III 18 Job submission components most simple case • make access decision • figure out a local policy mapping (unix account) • log what you did • run the job

  17. Grid Middleware III 19 Gatekeeper LCAS User accept VOMS Authentication Context+ JobInfo banlist LCAS authZ call out exectbl • LCMAPS open, learn,&run: • … and return legacy uid C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy Job Manager fork+exec args or submit VOMSpseudo-cert Job Submission (classic case) • user authenticates to a gatekeeper • provides proxy with identity & attributes • provides job information (RSL) • gatekeeper verifies integrity and authN • do an authZ callout(in our case LCAS) • the AuthZ frameworkcalls PDPs • do credential mapping • run the job manager

  18. Grid Middleware III 20 Policy Decision modules Typical PDPs • Blacklist and whitelist • VOMS attributes (group/role based access) • Proxy lifetime constraints • Checking quality of authentication tokens (OIDs) • timeslots As many of these PDPs are (still) local, the grid is missing the ‘big red button’ …

  19. Grid Middleware III 21 PDP configuration • A PDP is driven by a policy language • typical choice is XACML

  20. Policy languages Driving the PDP

  21. Grid Middleware III 23 Policy Evaluation (a reminder)

  22. Grid Middleware III 24 Policy Languages • Home-grown languages • infinite number out there … • XACML • structured “Subject, Resource, Action” triplets • supports logical constructs (and, or) • also includes a retrieve/push operation** • SAML • assertion mark-up, but can also be used to express policies** • not typically used as such (XACML has a preference in the community, since it is more expressive for ACLs) • GACL (Grid ACL) • semantically a subset of XACML • can be translated back and forth • comprehensible for sysadmins 

  23. Grid Middleware III 25 SAML – conveying assertions • Security Assertion Mark-up Language • XML format for exchanging assertions over the wire • a message exchange protocol: how to ask and get assertions • OASIS standard • in itself, SAML does not define the integrity of the assertion • SAML assertion itself is typically signed using XML Signature when travelling between untrusted end-points

  24. Grid Middleware III 26 SAML assertion types • Authentication Assertion • Attribute Assertion • Authorisation Decision

  25. Grid Middleware III 27 All assertions have some common information • Issuer and issuance timestamp • Assertion ID • Subject • Name plus the security domain • Optional subject confirmation, e.g. public key • “Conditions” under which assertion is valid • SAML clients must reject assertions containing unsupported conditions • Special kind of condition: assertion validity period • Additional “advice” • E.g., to explain how the assertion was made

  26. Grid Middleware III 28 Attribute Assertion • An issuing authority asserts that: • subject S • is associated with attributes A, B, … • with values “a”, “b”, “c”… • Typically this would be gotten from an LDAP repository • “john.doe” in “example.com” • is associated with attribute “Department” • with value “Human Resources”

  27. Grid Middleware III 29 SAML Attribute Assertion • <saml:Assertion …> <saml:Conditions …/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifierSecurityDomain=“smithco.com” Name=“joeuser” /> </saml:Subject> <saml:Attribute AttributeName=“PaidStatus” AttributeNamespace=“http://smithco.com”> <saml:AttributeValue>PaidUp </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement></saml:Assertion>

  28. Grid Middleware III 30 AuthZ Decision Assertion • An issuing authority decides whether to grant the request: • by subject S • for access type A • to resource R • given evidence E • The subject could be a human or a program • The resource could be a web page or a web service, for example

  29. Grid Middleware III 31 SAML Authorization Decision Assertion • <saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationStatement Decision=“Permit” Resource=“http://jonesco.com/rpt_12345.htm”> <saml:Subject> <saml:NameIdentifierSecurityDomain=“smithco.com” Name=“joeuser” /> </saml:Subject> </saml:AuthorizationStatement></saml:Assertion>

  30. Grid Middleware III 32 XACML: access control • XACML well suited to express local policies • can interoperate with incoming SAML assertions by translation • works on triplet (subject, resource, action) – RULE –> (decision [,obligation])

  31. Grid Middleware III 33 XACML policy type

  32. Grid Middleware III 34 XACML rules • a (set of) conditions that evaluate the incoming triples and result in a decision

  33. Grid Middleware III 35 XACML request example • <AAARequest> • <Subject Id="subject"> • <Attribute AttributeId="subject:subject-id" Issuer="admin@gaaa.collaboratory.nl"> • <AttributeValue>WHO740@users.collaboratory.nl</AttributeValue> • </Attribute> • <Attribute AttributeId="subject:role" Issuer="admin@gaaa.collaboratory.nl"> • <AttributeValue>Analyst</AttributeValue> • </Attribute> • </Subject> • <Resource> • <Attribute AttributeId="resource:resource-id" Issuer="admin@gaaa.collaboratory.nl"> • <AttributeValue>http://xps1.example.org/XPS1</AttributeValue> • </Attribute> • </Resource> • <Action> • <Attribute AttributeId="action:token" Issuer="admin@gaaa.collaboratory.nl"> • <AttributeValue>SubmitJob</xacmlcontext:AttributeValue> • </Attribute> • </Action> • <Environment> • <Attribute AttributeId="environment:issue-time" Issuer="admin@gaaa.collaboratory.nl"> • <AttributeValue>2001-12-17T10:30:00</AttributeValue> • </Attribute> • </Environment> • </AAARequest> XACML example from Yuri Demchenko, collaboratory.nl

  34. Grid Middleware III 36 XACML policy: login from 9 AM to 5 PM <Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue>SampleServer</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule RuleId="LoginRule" Effect="Permit"> <!-- Only use this Rule if the action is login --> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch> <AttributeValue>login</AttributeValue> <ActionAttributeDesignator AttributeId="ServerAction"/> </ActionMatch> </Action> </Actions> </Target> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/> </Apply> <AttributeValue>09:00:00</AttributeValue> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/> </Apply> <AttributeValue>17:00:00</AttributeValue> </Apply> </Condition> </Rule> </Policy>

  35. Grid Middleware III 37 Simpler policy languages • XACML is too expressive to be understood by people • so • lots of graphical editors (not so handy for large-scale adminstration) • translators from and to simpler languages • Example: GACL, the Grid ACL language

  36. Grid Middleware III 38 GACL example <?xml version="1.0"?><gacl version="0.0.1"><entry> <person> <dn>/O=dutchgrid/O=users/O=nikhef/CN=Willem van Leeuwen</dn> </person> <allow><read/><write/></allow> <deny><admin/></deny></entry> <entry> <voms-cred> <vo>iteam</vo> <group>/iteam</group> </voms-cred> <allow><read/><write/></allow> <deny><list/><admin/></deny></entry></gacl> This piece of GACL is for use with the SlashGrid filesystem, i.e. is geared towards file system operations.see www.gridsite.org

  37. Credential mapping and virtual workspaces

  38. Grid Middleware III 40 Credential Mapping For legacy jobs, need to privision an environment • Unix account • persistent (grid-mapfile) • group account (looses tracability/accountability) • dynamic assignment pool-accounts • pool-accounts with expiration (**) • Virtual machines

  39. Grid Middleware III 41 grid-mapfile • static mapping between grid user and local uid • cannot support multiple-VO membership • or user needs a new identity for each VO • combines authZ and mapping

  40. Grid Middleware III 42 poolaccounts • minimal modification to the gridmap-file code • same file format • uses a state directory where DNs are associated with unix accounts (using hard links, as they are atomic across NFS) • account mapping to “.pool” -> pool000, pool001, pool002, … • when the account mapping is requested • look in a state directory if this DN has an account mapping • if so, return this mapping • otherwise, pick next unused account from the pool and make a hardlink between DN and accountname file • return that mapping • periodic clean up of the gridmapdir is possible • but dangerous, as jobs may still be running or files left

  41. Grid Middleware III 43 Gridmapdir associations • $ ls -li /share/grid-security/gridmapdir/ • ... • 7635756 –rw-r--r-- 2 Jan 8 19:44 %2fo%3ddutchgrid%2fo%3dusers%2fo%3dnikhef%2fcn%3ddavid%20groep • 7635756 -rw-r--r-- 2 Jan 8 19:44 dteam060 • ...

  42. Grid Middleware III 44 LCMAPS • There are many ways to collect credentials in a site • /etc/passwd, NIS, NIS+, LDAP, Hesiod, MySQL • need a extensible, pluggable framework • Backward compatible with existing systems (grid-mapfile) • Support for multiple VOs per user (and thus multiple UNIX groups) • Mimimum system administration • Poolaccounts • Pool”groups” • Boundary conditions • Has to run in privileged mode • Has to run in process space of incoming connection (for fork jobs)

  43. Grid Middleware III 45 LCMAPS – functionality view • Unix mapping based on VOMS groups, roles • Supports pool groups as well as pool accounts • Granularity set by the site administrator (see example) • Primary group set to first VOMS group • for accounting purposes • for use by schedulers in setting priority • Identity set before job gets to batch system • accounting based on batch system data needs specific USER id for each job submitted • traceability of system/network activity inside the job or ~wrapper • limit impact of a compromised identity (so as not to hurt production)

  44. Grid Middleware III 46 LCMAPS – control flow GK LCMAPS Credential Acquisition • User authenticates using (VOMS) proxy • LCMAPS library invoked • Acquire all relevant credentials • Enforce “external” credentials • Enforce credentials on current process tree at the end • Run job manager • Fork will be OK by default • Batch systems may need primary group explicitly • Batch systems will need updated (distributed) UNIX account info • Order and function: policy-based & Enforcement CREDs Job Mngr

  45. Grid Middleware III 47 LCMAPS Acquisition and Enforcement Need two phases • Acquisition (while in privileged mode) • access to root-only-readable files with, e.g., LDAP passwords • access to host certificate/key for remote communications • Enforcement • Do actual setuid(2) and initgroups(2) calls • from that point on, it’s irreversible • must be within the running process

  46. Grid Middleware III 48 LCMAPS – modules • Modules represent atomic functionality • VOMSextract VOMS credentials from the proxy (A) • PoolAccountsfrom username assign unique uid (A) • PoolGroupsfrom (VOMS) groupname assign unique gid (A) • LocalAccountfrom username assign local existing unique uid (A) • LocalGroupsfrom (VOMS) groupname assign local existing gid (A) • VOMS PoolAccountsfrom (VOMS) username assign unique uid (A) • AFS/Krb5 get token based on user DN info (A) • POSIX processsetuid() and setegid() (E) • POSIX LDAP update distributed user database (E) • Krb5 run job via k5cert (E) • …

  47. Grid Middleware III 49 LCMAPS – policy evaluation • State machine approach (superset of boolean expressions) • Policy description file: FALSE LocalAccount VOMS-group LDAP POSIX PoolAccount TRUE /opt/edg/etc/lcmaps/lcmaps.db path = /opt/edg/lib/lcmaps/modules localaccount ="lcmaps_localaccount.mod \ -gridmapfile /etc/grid-security/grid-mapfile" poolaccount = "lcmaps_poolaccount.mod -gridmapfile /etc/grid-security/grid-mapfile" posix_enf = "lcmaps_posix.mod -maxuid 1 -maxpgid 1 -maxsgid 32" voms = "lcmaps_voms.mod -vomsdir /etc/grid-security/certificates \ -certdir /etc/grid-security/certificates" standard: voms -> poolaccount | localaccount localaccount -> posix_enf poolaccount -> ldapldap -> posix_enf

  48. Grid Middleware III 50 example groups # groupmapfile "/VO=atlas/GROUP=/atlas/phys-*/ROLE=production" atlphprd "/VO=atlas/GROUP=/atlas/det-*/ROLE=production" atldtprd "/VO=atlas/GROUP=/atlas/simul-*/ROLE=production" atlsiprd "/VO=atlas/GROUP=/atlas/*" atlgnusr "/VO=EGEE/GROUP=/EGEE/picard/Role=Manager" iteamsgm “/VO=Wilma/GROUP=/Wilma/bfys/Role=prod” wilmgr "/VO=Wilma/GROUP=/Wilma/*" .wilma VOMS to Unix domain mapping * Syntax as per VOMS attribute naming in 2.6 • Groups can be used for setting scheduling priorities, accounting &c. • If site supports it, a single uniform pool of UIDs can be used for all GIDs • For the “fork” JM, and for sites with a modifiable userdb, the job will collect all supplementary gids, as per the VOMS proxy

  49. Grid Middleware III 51 example gridmap # gridmapfile "/VO=atlas/GROUP=/atlas/phys-*/ROLE=production" .aphpd "/VO=atlas/GROUP=/atlas/det-*/ROLE=production" .adtpd "/VO=atlas/GROUP=/atlas/simul-*/ROLE=production" .asipd "/VO=atlas/GROUP=/atlas/*" .agnu "/VO=EGEE/GROUP=/EGEE/picard/Role=Manager" .isgm “/VO=Wilma/GROUP=/Wilma/bfys/Role=prod” .wgr #"/VO=Wilma/GROUP=/Wilma/*" CANNOT BE ENFORCED VOMS to Unix domain mapping … or using poolaccounts with a static group association * Syntax as per VOMS attribute naming in 2.6 • But you need a sufficiently large pool for each group • Only the primary group and its fixed assoc. supplementaries will be set

  50. Grid Middleware III 52 LCMAPS – caveats • Unix mapping based on VOMS groups, roles, and capabilities • Possibly pool groups as well as pool accounts • Granularity set by the site administrator (see example following) • Primary group set to first VOMS group – accounting • More than one VO/group per grid user allowed [but…] • Each VOMS unique FQAN listed translates into 1 Unix group id • Each user-FQAN combination translates into 1 Unix user id • New mechanisms could mitigate issues: • groups-on-demand, support granularity at any level • Central user directory support (nss_LDAP, pam-ldap) Not ready – and priorities have not been assigned to this yet.

More Related