Bài giảng XML Web Services Security

esData origin authenticationMarch 27, 2003. Vrije Universiteit, Amsterdam27XML Web Services SecurityAuthorisationTraditional systems:Determine whether a particular operation is allowed based on authenticated identity of requester and local informationGrid systems:Determine whether access to resource/operation is allowedAccess control list associated with resources, principal or authorised programsDistributed Authorisation Distributed maintenance of authorisation informationOne approach: Embed attributes in certificatesRestricted proxy: authorisation certificate that grants authority to perform operation on behalf of grantorAlternative: separate authorisation serverMarch 27, 2003. Vrije Universiteit, Amsterdam28XML Web Services SecurityAssurance, Accounting, AuditAssuranceWhen service is requested, to assure that candidate service provider meets requirementsAccountingMeans of tracking, limiting or changing for consumption of resourcesAuditRecord operations performed by systems and associate actions with principalsFind out what went wrong: typical role of Intrusion Detection SystemsMarch 27, 2003. Vrije Universiteit, Amsterdam29XML Web Services SecurityOGSA SecurityBuilt upon WS SecurityMarch 27, 2003. Vrije Universiteit, Amsterdam30XML Web Services SecurityOGSA Security Roadmap - Specifications (1)NamingOGSA Identity Specification OGSA Target/Action Naming Specification OGSA Attribute and Group Naming Specification Transient Service Identity Acquisition Specification Translating between Security RealmsIdentity Mapping Service SpecificationGeneric Name Mapping SpecificationPolicy Mapping Service SpecificationCredential Mapping Service Specification Authentication Mechanism AgnosticCertificate Validation Service SpecificationOGSA-Kerberos Services Specifications Pluggable Session Security GSSAPI-SecureConversation Specification March 27, 2003. Vrije Universiteit, Amsterdam31XML Web Services SecurityOGSA Security Roadmap - Specifications (2)Pluggable Authorization Service OGSA-Authorization Service SpecificationAuthorization Policy Management Coarse-grained Authorization Policy Management SpecificationFine-grained Authorization Policy Management Specifications Trust Policy Management OGSA Trust Service Specification Privacy Policy Management Privacy Policy Framework SpecificationVO Policy ManagementVO Policy Service Specification DelegationIdentity Assertion Profile SpecificationCapability Assertion Profile SpecificationMarch 27, 2003. Vrije Universiteit, Amsterdam32XML Web Services SecurityOGSA Security Roadmap - Specifications (3)Firewall "Friendly" OGSA Firewall Interoperability Specification Security Policy Expression and ExchangeGrid Service Reference and Service Data Security Policy Decoration Specification Secure Service OperationSecure Service’s Policy and Processing Specification Service Data Access Control Specification Audit and Secure Logging OGSA Audit Service Specification OGSA Audit Policy Management SpecificationMarch 27, 2003. Vrije Universiteit, Amsterdam33XML Web Services SecurityTrust establishment process (1)1. Binding an entity identity to a Distinguished Name (“DN” - the subject name in an X.509 identity certificate)Trust in this step is accomplished through the (published and audited) policy based identity verification procedures of the Certification Authority that issues the identity certificates2. Binding a public key to the DN (generating an X.509 certificate)Trust in this step is accomplished through the (published and audited) policy based operational procedures of the issuing Certification Authority (“CA”).3. Assurance that the public key that is presented actually represents the userTrust in this step comes from the cryptography and protocols of Public Key Infrastructure.4. Assurance that a message tied to the entity DN could only have originated with that entity:Trust that a message signed by a private key could only have been signed by the private key corresponding to the public key (and therefore the named entity via X.509 certs) comes from public key cryptographyTrust in this step is also through user key management (the mechanism by which the user limits the use of its identity), which is assured by user education, care in dealing with one’s cyber environment, and shared understanding as to the significance of the private key.March 27, 2003. Vrije Universiteit, Amsterdam34XML Web Services SecurityTrust establishment process (2)5. Mutual authentication, whereby two ends of a communication channel agree on each other’s identityTrust in this step is through the cryptographic techniques and protocols of the Transport Level Security (“TLS”) standard.6. Delegation of identity to remote Grid systemsTrust in this step is through the cryptographic techniques and protocols for generating, managing, and using proxy certificates that are directly derived from the CA issued identity certificates.March 27, 2003. Vrije Universiteit, Amsterdam35XML Web Services SecurityRemote Authentication, Delegation, and Secure Communication in GRIDRemote authentication is accomplished by techniques that verify a cryptographic identity in a way that establishes trust in an unbroken chain from the relying party back to a named human, system, or service identity. This is accomplished in a sequence of trusted steps, each one of which is essential in order to get from accepting a remote user on a Grid resource back to a named entity.Delegation involves generating and sending a proxy certificate and its private key to a remote Grid system so that remote system may act on behalf of the user. This is the essence of the single sing-on provided by the Grid: A user / entity proves its identity once, and then delegates its authority to remote systems for subsequent processing steps.A secure communication channel is derived from the Public Key Infrastructure process and the IETF Transport Level Security protocol.March 27, 2003. Vrije Universiteit, Amsterdam36XML Web Services SecurityGlobus Grid Security Infrastructure (GSI)Operational solution providing security infrastructure for Globus ToolkitsTargeted problems: Thousands of users – thousands of Certs – many of CAs (with different policies)Grid-wide user group and roles are neededNo grid-wide logging or auditingNeed for anonymous usersIntended to evolve into OGSA SecurityGSI ComponentsProxy Certificate ProfileProvides proxy credentials to allow for single sign-on and to provide delegated credentials for use by agent and serversOnline Credential Retrieval to create and manage proxy certificatesImpersonation certificate and restricted delegation certificateMarch 27, 2003. Vrije Universiteit, Amsterdam37XML Web Services SecurityProxy Certificate ProfileImpersonation – used for Single-Sign-On and DelegationUnrestricted ImpersonationRestricted Impersonation defined by policyProxy with Unique Name Allows using in conjunction with Attribute CertUsed when proxy identity is referenced to 3rd party, or interact with VO policyProxy Certificate (PC) properties: It is signed by either an X.509 End Entity Certificate (EEC), or by another PC. This EEC or PC is referred to as the Proxy Issuer (PI). It can sign only another PC. It cannot sign an EEC. It has its own public and private key pair, distinct from any other EEC or PC. It has an identity derived from the identity of the EEC that signed the PC. Although its identity is derived from the EEC's identity, it is also unique. It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC. March 27, 2003. Vrije Universiteit, Amsterdam38XML Web Services SecurityReference: PKC vs AC: PurposesX.509 PKC binds an identity and a public keyAC is a component of X.509 Role-based PMIAC contains no public keyAC may contain attributes that specify group membership, role, security clearance, or other authorisation information associated with the AC holderAnalogy: PKC is like passport, and AC is like entry visaPKC is used for Authentication and AC is used for AuthorisationAC may be included into Authentication messagePKC relies on Certification Authority and AC requires Attribute Authority (AA)March 27, 2003. Vrije Universiteit, Amsterdam39XML Web Services SecurityPKC vs AC: Certificates structureX.509 PKCVersionSerial numberSignatureIssuerValiditySubjectSubject Public key infoIssuer unique identifierExtensionsACVersionHolderIssuerSignatureSerial numberValidityAttributesIssuer unique IDExtensionsMarch 27, 2003. Vrije Universiteit, Amsterdam40XML Web Services SecurityX.509 PKC Fields and Extensions – RFC 3280X.509 PKC FieldsSerial NumberSubjectSubject Public KeyIssuer Unique IDSubject Unique IDX.509 PKC ExtensionsStandard ExtensionsAuthority Key IdentifierSubject Key IdentifierKey UsageExtended Key UsageCRL Distribution ListPrivate Key Usage PeriodCertificate PoliciesPolicy MappingsSubject Alternative NameIssuer Alternative NameSubject Directory AttributesBasic ConstraintsName ConstraintsX.509 PKC FieldsPrivate ExtensionsAuthority Information AccessSubject Information AccessCustom ExtensionsMarch 27, 2003. Vrije Universiteit, Amsterdam41XML Web Services SecurityAC Attribute Types and AC ExtensionsAC Attribute TypesService Authentication InformationAccess IdentityCharging IdentityGroupRoleClearanceProfile of AC AC ExtensionsAudit IdentityTo protect privacy and provide anonymity May be traceable via AC issuerAC TargetingAuthority Key IdentifierAuthority Information AccessCRL Distribution PointsMarch 27, 2003. Vrije Universiteit, Amsterdam42XML Web Services SecurityOther Technologies to look for IIDSSIP (Session Initiation Protocol) based technologiesInstant Messaging and Presence Protocol – SIP basedMarch 27, 2003. Vrije Universiteit, Amsterdam43XML Web Services SecurityXML Web Services technologies for IIDSDiscussionMarch 27, 2003. Vrije Universiteit, Amsterdam44XML Web Services Security