1 / 28

Security Approaches and Requirements

Security Approaches and Requirements. John Watt NCeSS Conference 2008 - Workshop 3 Data Management through e-Social Science June 18th 2008. Authentication and Authorisation. Authentication is the establishment of IDENTITY Your passport is an identity token

lila-hendrix
Télécharger la présentation

Security Approaches and Requirements

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. Security Approaches and Requirements John Watt NCeSS Conference 2008 - Workshop 3 Data Management through e-Social Science June 18th 2008

  2. Authentication and Authorisation • Authentication is the establishment of IDENTITY • Your passport is an identity token • Issued by INTERNAL National Authority upon in-person presentation of information (e.g. birth certificate) • Authorisation is the establishment of PERMITTED ACTION(S) • An entry visa is an authorisation statement • Issued by EXTERNAL foreign authority upon presentation of specific information (e.g. work permit)

  3. Typical AuthN and AuthZ • User registers with University IT Services when they start their course/job • Terms and Conditions form • Present staff/student ID number • Means user has been identified to University • User is supplied with Username and Password combination • This is the user’s day-to-day digital identity • Issued by a well-known entity (the University) • Satisfies the University’s own registration protocol • a trustworthy authentication token…?

  4. Authentication and Authorisation on the Grid • Authentication on the Grid is performed through X.509 digital certificates • Issued by a trusted National/Regional Authority • a Certification Authority (CA) • Technically, the CA implements a Public Key Infrastructure (PKI) • Authorisation on the Grid is performed by… • grid-mapfile, VOMS, PERMIS, OMII-SP CCP, Attribute Certificates (ACs), Akenti, CAS, Active Directory groups…. V O M S

  5. Proxy Certificates • X.509 Certificates have interesting properties • Short-lived copies of the original certificate can be made to automatically propagate through the Grid • Proxy Certificates • Short-lived to mitigate intruder actions • Enables Single Sign-On to Grid • They carry a digital signature that tells if the information contained in the certificates has been tampered • MyProxy is a tool which allows repository access to the certificate via a username/password • User doesn’t need to handle the certificate

  6. Multiple Identities • A national CA issues a national-level ID • Large footprint, enabling certificate • Not a user’s familiar identity • A University issues a local-level ID • Small footprint, only recognised on campus • User is familiar with this identity • Both these identities have well-known user registration procedures • But a local identification will ALWAYS be a more authentic token • User is known at the institution • Home site can revoke privileges faster than a remote site

  7. Shibboleth • Shibboleth federates your local identity across a network of trusting sites • Collection of sites managed by a “Federation” • Responsible for registering participants and supplying metadata for up-to-date resource info • In UK, managed by the UK Access Management Federation http://www.ukfederation.org.uk • Federation services may be accessed with the user’s home University credentials, regardless of location • Resources no longer need to do user registration • Single Sign-On Solution • Pseudo-anonymous access possible

  8. Shibboleth • Shibboleth/SAML defines interactions between • An IDENTITY PROVIDER (IdP) • Represents a user’s home institution • Asserts user information to the federation • A SERVICE PROVIDER (SP) • Represents the resource that is being accessed • Consumes the user’s information on behalf of the protected application • An optional Where Are You From? (WAYF) • Shibboleth is an Apache module that triggers the SAML mechanism when a protected web directory is requested. SP WAYF? IdP mod_shib

  9. Shibboleth SAML Attributes • Shibboleth provides a mechanism for additional information about the user to be securely exported • These SAML attributes may be used for authorisation and access control • IdP provides a policy-driven set of user attributes to be transmitted to an SP, which has a separate policy-driven reception policy • These attributes typically hold ACCESS RIGHTS • Text String Roles (staff, student, director, minion..) • Attribute Certificates (Certs with extra info) • Supports Role-Based Access Control (RBAC)

  10. eduPerson Schema • Attempts to standardise a set of core information that can be provided about users • eduPersonAffiliation • MEMBER, STUDENT, AFFILIATE • eduPersonTargetedID • 4TyY&ZAWSZ7yGB7e56@nesc.gla.ac.uk • eduPersonEntitlement • Roles, Privileges (nanoCMOS_webManager) • eduPersonPrincipalName • John Watt • Only one that contains revealing information

  11. Shibboleth Operation • Enter URL of Service Provider • https://www.nanocmos.ac.uk

  12. Shibboleth Operation • Where Are You From? • Select your institution from the drop-down menu • Will be “National e-Science Centre (Glasgow)” for now

  13. Shibboleth Operation • Authenticate with username/password

  14. Shibboleth Operation • SAML is collecting attributes about the user • Then redirects you to the URL you originally requested…

  15. Shibboleth Operation • Logged In

  16. Shibboleth Summary • Allows a user’s home University login to be recognised across a national-scale network of trusted sites • Provides extra info (attributes) which may be used for access control • Single Sign-On to Services • User management done at user’s home site • Issues: • How to link with national CA credential? • Coordination required between requirements of IdPs and SPs

  17. Authorisation • Many ways to do authorisation • UNIX Permissions on account • User abilities are enforced by sys admin on single accounts per user • Account accessed through a grid mapfile • List of user X.509 DNs and the account they map to • Admin nightmare when scaled up • Role Based Access Control • Guided by concept that users may come and go from an organisation, but the actual jobs and roles will remain relatively static.

  18. Role Based Access Control (RBAC) TESCO (ALL STORES) ACCESS CONTROL LIST Policy: Jim Bowen 10% off all goods Richard Whiteley 10% off all goods Noel Edmonds 10% off all goods Des O’Connor 10% off all goods Bob Monkhouse 10% off all goods Terry Wogan 10% off all goods ……..etc etc etc etc etc etc TESCO (ALL STORES) ROLE-BASED ACCESS CONTROL Give all customers (Jim, Richard, Noel, Des etc….) a Loyalty Card which entitles them to 10% off Policy: Loyalty card holder 10% off all goods

  19. Attribute Certificates • Shibboleth provides a text string role to a service • Transport is secure and understood • Source of the attribute can never be known • Trust of IdP essential, but safeguards needed… • Attribute Certificates (ACs) are X.509 certificates with extra information appended • Used to convey text string roles in digital certificate • With advantaged X.509 brings • i.e. digital signature, validity information Role + role

  20. Attribute Certificates • Many technologies can exploit digitally signed ACs • VOMS • Virtual Organisation Management Service • Fully supported by NGS • Involves a central repository managed by a VO admin • PERMIS • Privilege and Role Management Infrastructure Standards Validation • Generic PMI (privilege management infrastucture) solution – decentralised • Recognises VOMS ACs, normal X.509, plus XACML response/request

  21. Security Ingredients VOMS

  22. Portals • Browser based access to Web/Grid Services • Can hide user from • Certificate Management and Operations • Command line obscurity • Grid middleware atheism • Firewall restrictions • Can implement portal side security to complement service-side security • Joining of these two domains is another research hot-topic!

  23. The NeSC Model • User logs into portal via Shibboleth • User’s portal view is filtered according to the SAML attributes presented by the IdP • User can only invoke services they are entitled to attributes

  24. The NeSC Model • Portal retrieves non-local credentials from VOMS/PERMIS/MyProxy… • Based on DN info supplied by IdP VOMS (local?)

  25. The NeSC Model VOMS • Portal exports appropriate credential to desired service NGS Data proxy Store

  26. The Big Picture • Complementary local and external security • Must meet the requirements of the external service • Hide user from complex interactions Portal Home Institution The Outside World (Grid, data sources)

  27. Issues • Portal side security is well known and present now • UK Federation enables a vast user base • Every staff and student in UK academia? • A select few…? • Challenge lies in bridging the requirements of external services • Are the resources willing to deploy alternate security infrastructures? • Grid enabled? (GT4, OGSA-DAI) • If alternate standard prevalent, can we speak their language?

  28. New Technologies • SAML2 Holder-of-key Assertion

More Related