1. 1 GT4 Security Tutorial Rachana Ananthakrishnan Charles Bacon

2. 2 Presentation 1 Encryption Signature Certificates

3. 3 Encryption l Encryption is the process of taking some data and a key and feeding it into a function and getting encrypted data out l Encrypted data is, in principal, unreadable unless decrypted l Decryption is the reverse process Encryption Function

4. 4 Asymmetric Encryption l Encryption and decryption functions that use a key pair are called asymmetric l Data is encrypted with one key, the other key must be used to decrypt the data u And vice versa Encrypt Decrypt Encrypt

5. 5 Public and Private Keys l With asymmetric encryption each user can be assigned a key pair: a private and public key Private key is known only to owner Public key is given away to the world

6. 6 Public and Private keys l Anything encrypted with the public key can only be decrypted with the private key l And vice versa l Since the private key is known only to the owner, this is very powerful. Encrypt Decrypt

7. 7 Digital Signatures l Digital signatures allow the world to u determine if the data has been tampered u verify who created a chunk of data

8. 8 Digital Signatures l Digital signatures are generated by u Creating hash of the data u encrypting the hash with my private key l The resulting encrypted data is the signature l This hash can then be decrypted only by my public key Hash Encrypt

9. 9 Digital Signature l Recipient of data and signature: u Compute hash of data u Decrypt signature to get hash u Compare hash to see if they match Compute Hash =? Decrypt

10. 10 Public Key Infrastructure (PKI) l PKI allows you to know that a given public key belongs to a given user l PKI builds off of asymmetric encryption: u Each entity has two keys: public and private u The private key is known only to the entity l The public key is given to the world encapsulated in a X.509 certificate Owner

11. 11 Certificates l A X.509 certificate binds a public key to a name l It includes a name and a public key (among other things) bundled together and signed by a trusted party (Issuer) Name Issuer Public Key Validity Signature

12. 12 Certificates l Question: Who signs certificates? l Answer: A small set of trusted entities known as Certification Authorities (CAs) Issuer? Name Validity Public Key

13. 13 Certification Authorities (CAs) l A Certification Authority is an entity that exists only to sign user certificates l The CA signs it’s own certificate which is distributed Name: CA Issuer: CA CA’s Public Key Validity CA’s Signature

14. 14 Certification Authorities (CAs) l The public key from the CA certificate can then be used to verify issued certificates Name Issuer Validity Public Key Signature Hash =? Decrypt Name: CA Issuer: CA CA’s Public Key Validity CA’s Signature

15. 15 Certificate Policy (CP) l Each CA has a Certificate Policy (CP) which states u who it will issue certificates to u how it identifies people to issue certificates to l Lenient CAs don’t pose security threat, since resources determine the CAs they trust.

16. 16 Requesting a Certificate l To request a certificate a user starts by generating a key pair l Private key is pass- phrase protected

17. 17 Certificate Request l The user then signs their own public key to form what is called a Certificate Request l Email/Web upload Sign Certificate Request Public Key

18. 18 Registration Authority (RA) l The user then takes the certificate to a Registration Authority (RA) l Vetting of user’s identity l Often the RA coexists with the CA and is not apparent to the user Certificate Request Public Key ID

19. 19 Certificate Issuance l The CA then takes the identity from the RA and the public key from the certificate request l It then creates, signs and issues a certificate for the user Certificate Request Public Key Name Issuer Validity Public Key Signature Name

20. 20 Certificate Revocation l Why revoke: u Key compromised u Malicious user l Certificate Revocation Lists u List of serial numbers revoked u Signed by CA l Periodic Updates

21. 21 GSI: Proxy Credentials l Proxy credentials are short-lived credentials created by user u Proxy signed by certificate private key l Short term binding of user’s identity to alternate private key l Same effective identity as certificate SIGN

22. 22 GSI: Proxy Credentials l Stored unencrypted for easy repeated access l Chain of trust u Trust CA -> Trust User Certificate -> Trust Proxy l Key aspects: u Generate proxies with short lifetime u Set appropriate permissions on proxy file u Destroy when done

23. 23 Exercise 1 Acquiring a certificate Starting a webservices container

24. 24 The Exercise Code l We’ll be starting with a GT4 counter service and adding different kinds of security to the service and clients l To start, we’ll need to get an X.509 certificate and install the GT4 webservices container l All your exercise instructions are in the student-notes.html file u Follow the instructions until you get to the beginning of Exercise 2

25. 25 Exercise Corrections l Files are in $HOME rather than $HOME/tutorial l GT core file is gt-install.tar.gz rather than ws-core*.gz l If your machine’s date is incorrect, please contact us so we can fix it

26. 26 Presentation 2 Authentication Message Protection Security Descriptors

27. 27 Introduction l Authentication u Establishing identity of remote entity u Prove holder of private key corresponding to presented certificate l Message Protection u Integrity of message, digital signatures u Privacy of message, encryption

28. 28 Authentication Schemes l GSI Secure Message u Each individual message is secured u XML Signature using private key u XML Encryption using public key u Replay Attack Prevention u Performance hits due to XML handling

29. 29 l GSI Secure Conversation u Handshake to establish secure context u Signature and encryption using symmetric key u Anonymous access support u Most effective on repeated use of context u GT initializes Apache XML Security Library appropriately Authentication Schemes

30. 30 l GSI Secure Transport u Secure Sockets u Encryption and signature using symmetric key u “https” protocol u Standalone container-level configuration u Default configuration u If routed, end to end security is not feasible Authentication Schemes

31. 31 GT4 Server-side features l Configure required authentication as policy u At service or resource level u Programmatic or security descriptors l Message Protection options u Integrity and Privacy l Server response u Same authentication scheme as request

32. 32 GT4 Client-side features l Configurable client side authentication u Per invocation granularity u Properties on the Stub u Programmatically or Security Descriptors l Message Protection options u Integrity and Privacy u Default: Integrity protection

33. 33 Security Descriptor Overview l GT way of configuring security properties l Declarative security u Configure properties in files l Programmatic security u Descriptors as Java objects l Types of descriptors u Container u Service u Resource u Client

34. 34 Container Security Descriptor l Configured in global section of deployment descriptor u $GLOBUS_LOCATION/etc/globus_wsrf_core/ server-config.wsdd u Parameter: containerSecDesc u Can be done only in this file l Programmatically created l Only one instance of container security descriptor per JVM l Initialized at container startup only

35. 35 Service Security Descriptor l Service’s deployment descriptor as file u Parameter: securityDescriptor u Loaded as file or resource stream l Programmatically in service constructor l Initialized from file only on service initialization l Can be programmatically altered at any time

36. 36 Service Descriptor Example l Method specific authentication policy l Default authentication policy

37. 37 Resource Security Descriptor l Resource descriptor set programmatically l Load from file or use ResourceSecurityDescriptor object l Security Framework does not load or initialize l Identical to service security descriptor l Can be loaded as file or resource stream

38. 38 Client Security Descriptor l Security descriptor file u ((Stub)port).setProperty(Constants.CLIENT_DESCRI PTOR_FILE, fileName); u Absolute path or as resource stream or relative to $GLOBUS_LOCATION l Security descriptor object u ((Stub)port).setProperty(Constants.CLIENT_DESCRI PTOR, instance of ClientSecurityDescriptor);

39. 39 Client Descriptor Example l l l GSI Secure Transport, based on protocol: https

40. 40 Exercise 2 Service Security Descriptor Starting a webservices container

41. 41 The Exercise Code l In this exercise we will take a simple counter service with create/add/subtract/query operations and add authentication l To do this, we will first add a service security descriptor to add authentication to the operations l Then we will modify the four clients to use the appropriate kinds of authentication

42. 42 Adding the service sec. desc. l To add the security descriptor to the service, first we add a securityDescriptor property to the server-config.wsdd l Then we will edit the securityDescriptor file to define the kinds of authentication we want l Because we want to show as much variety as possible, we’ll set a number of different authentication methods on the different operations

43. 43 Adding the client sec. desc. l For the clients, we need to make the authentication method correspond to the matching operation’s authentication method l We’ll use both the Stub/properties approach and the client-side descriptor approach

44. 44 Presentation 3 Authorization

45. 45 Introduction l Authorization: u Determine if said entity can perform a said action on a said resource u Without this, any entity with valid certificate can access resource l Authentication required before authorization

46. 46 Server-side Authorization Framework l Establishes if a client is allowed to invoke an operation on a resource l Only authenticated calls are authorized l Attribute-based Authorization u Identity and Properties of an entity used in decision making l Authorization policy configurable at resource, service or container level

47. 47 Server-side Authorization Components l Policy Information Points (PIPs) u Collect attributes (subject, action, resource) l Policy Decision Points (PDPs) u Evaluate authorization policy l Authorization Engine u Orchestrates authorization process u Enforce authorization policy u Combining algorithm to renders a decision

48. 48 GT 4.0 Authorization Framework Authorization Engine (Deny-override) PIP1PIP2PIPnPDP1PDP2PDPn … … Authorization Handler Authentication Framework Identity and public credential of client Appropriate Authorization Engine Message Context (store attributes) Permit Deny Permit

49. 49 PIP Examples l X509 Certificate details as attributes l Method parameters as attributes l Attributes from an attribute service u VOMS, Shibboleth

50. 50 PDP Examples l Self Authorization u Same identity as remote entity l Gridmap Authorization u Entry in configuration file, gridmap file u Mapping from DN to local account l Identity Authorization u Matches configured identity

51. 51 Descriptor Configuration l Container/Service/Resource descriptor: u “ l Precedence order l Parameters: u Configured in deployment descriptor u Prefix and parameter name l u Exception is gridmap

52. 52 Client-side Authorization l Determines if said service/resource is allowed to cater to the client’s request l Pluggable authorization scheme u Defined interface, implement custom schemes l Configured as property on stub or using security descriptors l Examples: Self, Host, Identity, None l Default: Host

53. 53 Client-side Authorization l GSI Secure Transport u Done after handshake is completed l GSI Secure Conversation u Done after handshake is completed u Required when delegation is done l GSI Secure Message u Done after operation is complete u Use encryption to ensure correct server u Use client-side authorization to validate response

54. 54 l Authorization Element u l Values: u none u host u self u Expected DN as string l Does not support custom authorization configuration Client Descriptor Example

55. 55 Exercise 3 Adding authorization to the service Adding authorization to the clients

56. 56 The Exercise Code l This exercise will make the client and service both perform self authorization l First, exchange CounterService endpoints with a neighbor, and see that you can create/add/subtract/query/destroy on your neighbor’s service l Then add self authorization to the service and client

57. 57 Benefits of Self Authorization l Don’t forget that this authorization is mutual! l Your client will reject a service if you are somehow tricked into reaching a service that isn’t being run with your identity l Your service will reject clients who are not running with your identity

58. 58 Presentation 4 Resource Security

59. 59 Resource-level Security l Security Properties u Credentials u Authentication policy u Authorization policy l Resource Security Descriptor u Similar to service security descriptor u From file or programmatically l Highest precedence

60. 60 Writing Secure Resource public class TestResource implement SecureResource { ResourceSecurityDescriptor desc = null; public TestResource() { this.desc = new ResourceSecurityDescriptor(descFileName); } public ResourceSecurityDescriptor getSecurityDescriptor() { return this.desc; } } this.desc = new ResourceSecurityDescriptor(); // set properties programmatically this.desc.setGridMap(new GridMap());

61. 61 Resource Security Descriptor l Toolkit does not initialize, up to resource developer l Authorization parameters programmatically set u ResourceSecurityConfig class u Hashmap of properties

62. 62 Presentation 5 Secure Notifications

63. 63 Notifications l Server side: u Resource property is exposed as notification topics u Service has subscribe operation port type u Operation provider: SubscribeProvider l Client side: u Consumer, embedded container u Notification callback

64. 64 Notification Client CounterService Subscription Manager Service Container Notification Consumer Manager NotificationConsumerService Notification Callback Embedded Container subscribe(EPR) EPR

65. 65 Notification Security l Client side: u Secure container l Secure consumer resource u Secure subscribe invocation l Server side u Secure subscribe operation l Secure notification u Only one container descriptor per JVM

66. 66 Exercise 4 Adding auth/authz to resources Gridmap authorization

67. 67 The Exercise Code l What if we want other clients to access our counters? l In this exercise, we’ll let a list of authorized clients access our counters l Creating new counters will still be self authorized l New users will be added to the authorization list (or “gridmap”) via the addAuthorizedDN operation

68. 68 SecureTutorial CounterService l We’ll add the addAuthorizedDN operation to the service l The service will, in turn, call the addAuthorizedDN operation on the counter resource l The resource will implement SecureResource and set a PolicyDecisionPoint (PDP) with the GridMapAuthorization class

69. 69 Gridmap authorization l The gridmap authorization on the resource will let the authorized users use the add/subtract/query operations l But don’t forget that authorization is mutual! l We can’t use the self authorization on the client for this exercise, because we’ll be interacting with services running under other identities

70. 70 Exercise Notes l Shared EPR at: u /eprs/shared/lab-## u Example: /eprs/shared/lab-16

71. 71 Exercise 5 Notification security

72. 72 The Exercise Code l Almost all of the new code in the exercise is just to produce/consume notifications l The security is handled via a descriptor on the service side, and Stubs on the add client

73. 73 Presentation 6 Credential Configuration Host Authorization

74. 74 Types of Credentials l User u Private key is encrypted u Cannot be directly used in GT l Proxy u Both keys in same file u Private key unencrypted l Host u Private key unencrypted. u Typically protected by file system priviledges l Service u Similar to host key

75. 75 Descriptor Example l Can be configured in any descriptor file, server and client side l Proxy file name l Certificate and key filename u l Absolute file name, as resource stream, relative to $GLOBUS_LOCATION

76. 76 Related Utility API l To get resource credential u SecurityManager.getManager().getResourceSubject() l To get service credential u SecurityManager.getManager().getServiceSubject() l To get container credential u SecurityManager.getManager().getSystemSubject() l To get effective credential u SecurityManager.getManager().getSubject()

77. 77 Host Authorization l Expect host certificates used by remote entity l Typically container or service l Reverse resolution: IP to hostname

78. 78 Presentation 7 Anonymous Access

79. 79 Secure Transport Anonymous l Client does not need certificates l Service explicitly should allow such access l Authorization mechanism might fail

80. 80 Presentation 8 GSI Secure Message

81. 81 Secure Message Encryption l Encrypt with public key of remote entity u Host certificates, use hostcert.pem u User certificates, use usercert.pem l But encrypted private key, so not feasible in practice u Proxy certificates, use same proxy certificate! l Internally symmetric key is generated for performance reasons l Privacy better than integrity u since client authorization done after operation is invoked

82. 82 Exercise 6 Acquire hostcerts Setup host authorization for clients Add service-wide gridmap

83. 83 The Exercise Code l The last time we used our neighbor’s service, we used None authorization on the client. We can do better! l We’ll get a host certificate, and set it as the default identity container-wide. Remember that we can override at the service/resource level if we want

84. 84 Service gridmap l We will also setup a service-level gridmap. This will let us have authorized users create and destroy counters without having to use something like addAuthorizedDN l On the client side, we will only change to Host authorization. The client will expect a hostname that matches the IP address in the certificate subject

85. 85 Exercise 7 Anonymous access

86. 86 The Exercise Code l This is a brief exercise to show how to anonymous access works l We’ll show that clients don’t need a proxy to use anonymous access l We’ll also show how unauthenticated operations bypass authorization, allowing anonymous clients to access them l getValue is okay to expose to the world, but this lets us keep https://

87. 87 Exercise 8 GSI Secure Message

88. 88 The Exercise Code l This is a brief exercise to show how to setup GSI Secure Message security l We’ll need to have a copy of the service’s public key (in this case, the hostcert.pem we just setup) available to the client l The exercise also demonstrates the post- operation authorization

89. 89 Presentation 9 Delegation Run-As Configuration

90. 90 Delegation l Empower an entity with rights of another l Typical scenario: u Client empower server u One service empower another l Use of proxies for delegation

91. 91 GSI Delegation Certificate Request Certificate Delegated Credential

92. 92 Delegation l Types of delegation: u Limited u Full l Services can choose to reject limited proxies u Per service or resource configuration u Applies to all methods l Clients can control delegation path length u Limits misuse

93. 93 Delegation l Secure Conversation u Can delegate as part of protocol u Extra round trip with delegation u Full or limited delegation l Secure Message and Secure Transport u Cannot delegate as part of protocol

94. 94 Run As Configuration l Determines credential to associate with operation l Significant when callouts are used l Options: system, service, resource, caller l Default: resource l With caller, delegation required

95. 95 Exercise 9 Delegation The Bank Service

96. 96 The Exercise Code l This new service models a very simple bank account. You can create accounts, then deposit and withdraw funds l The depost/withdraw operations highlight run-as, operating under the caller’s identity

97. 97 Presentation 10 Delegation Service

98. 98 Delegation Service l Higher level service stores delegated credential l Two remote operations: u Delegate u Refresh l Delegated credential as WSRF resource u Protected with resource security

99. 99 Delegation Service l Client delegates and gets EPR l EPR as part of invocation to service l Service uses EPR to get credential l Client can refresh credential Client Service1 Service2 Service3 Delegation Service Hosting Environment Resources Delegate EPR Refresh DelegateRefresh

100. 100 Delegation Service l Two ways to get delegated credential: u Use Delegation EPR to get credential u Register a listener to get refresh updates l Advantages of Delegation Service: u Shared across multiple invocations u Shared across multiple services u Authentication protocol independent

101. 101 Exercise 10 The Delegation Service The Finance Service

102. 102 The Exercise Code l Pretend that we want to run a retirement planning service l The user wants to let us access the their bank account so we can tell them when they can retire l To accomplish this, they will create a delegated credential in the Delegation Service, then allow our finance service to access it

103. 103 The Exercise Code l This new service models a very simple bank account. You can create accounts, then deposit and withdraw funds l The depost/withdraw operations highlight run-as, operating under the caller’s identity

104. 104 The Finance Service l Recall that our bank service rejects limited proxies for deposit/withdraw operations, so the Finance Service can only query l Our simple Finance Service only takes an interest rate and number of years, then computes the result of that interest rate applied to that account for that number of years

105. 105 Presentation 11 GT 4.2 Features Other Interesting Security Components Planned Work

106. 106 GT 4.2 Features l Server-side Authorization Framework u Normalized representation u Entity as a collection of attributes u Merge relevant attributes from same entity u Access and Administrator rights u Pluggable combining algorithm u Default: Permit override with delegation of rights

107. 107 GT 4.2 Features l Client side authorization u Host or self authorization u No authorization during handshake l Security Descriptors u Schema validation u Cover more options

108. 108 Community Authorization Service l Manage rights in a VO l User, action, resource mapping l Generic framework l Rights as signed SAML Assertions l Web service interface u Administrator interface u Query interface l Back end database l Java clients

109. 109 Community Authorization Service l Push model u Proxy certificate u SOAP Header u GridFTP control Channel l Pull model u Authorization Service interface u Java PDP interface

110. 110 GridShib l Leveraging existing campus identity management l Shibboleth u Interface to campus identity management systems u Exposes campus identity and attributes in standard format l GridShib: u Plugins to interface with Grid tools u No new credentials, use existing attributes u Example: GridShib for GT l TeraGrid Testbed l Details: http://gridshib.globus.org/http://gridshib.globus.org/

111. 111 MyProxy l Credential Database l Leverage local authentication l Online CA l Trust certificate provisioning l Delegation to remote servers l Details: http://grid.ncsa.uiuc.edu/myproxy/

112. 112 Introduce l IDE for web service development u Supports GT 4.0 services and clients u GUI interface u Build schema, stubs, implementation class framework u Service level security supported l caBig Effort l Incubator project on dev.globus u http://dev.globus.org/wiki/Incubator/Introduce

113. 113 Planned Work l Authorization module separate from WS layers l Remote PIP and PDP support l Trust root validation callout l XACML interface for CAS l WS-Naming and Identifiers

114. 114 Reference l Authentication: u http://www.globus.org/toolkit/docs/4.0/sec urity/message/ http://www.globus.org/toolkit/docs/4.0/sec urity/message/ l Authorization: u http://www.globus.org/toolkit/docs/4.0/sec urity/authzframe/ http://www.globus.org/toolkit/docs/4.0/sec urity/authzframe/ l API u http://www.globus.org/api/javadoc- 4.0.0/globus_java_ws_core/