6/28/20151 Bringing Semantic Security to Semantic Web Services B. Ramamurthy

6/28/20152 Introduction Humans can read web pages and understand them, but their inherent meaning is not shown in a way that allows their interpretation by a computer (program). One way to enable machine-to-machine exchange and automated processing is to provide the information in such as way that computers can understand it. This is precisely the objective of the semantic web. The next generation of the Web will combine existing Web technologies with knowledge representation formalisms.

6/28/20153 Semantic Web Services Web Services WWW Semantic Web Semantic Web Services dynamic static

6/28/20154 RDF, OWL, WSDL-S RDF is a standard for creating descriptions of information. RDF is for simple semantics. OWL provides a language for defining structured web-based ontologies which allows a richer integration and interoperability of data among communities and domains. WSDL-S establishes a mapping between WSDL descriptions and ontological concepts.

6/28/20155 WSDL-S Example Semantics can be added to operations, messages, preconditions and efforts xmlns:sm=

6/28/20156 Authoring Tool for WSDL-S To create, represent, and manipulate WSDL- S documents WSDL4J can be used. WSDL4J provides Java APIs for WSDL parsing and generation. WSDL4J supports extensibility elements providing an easy mechanism to add new extensions.

6/28/20157 Web Services Security Background Standards are proposed or accepted regarding authentication, encryption, and identity management. RSA encryption, XML signatures, SAML – Security Assertion Markup Language There are 5 fundamental areas to consider: Message level protection, Message privacy, parameter checking, authentication, and authorization. This is application layer security (not network layer security).

6/28/20158 Application of RSA Lets say a person in Atlanta wants to send a message M to a person in Buffalo: Atlanta encrypts message using Buffalo’s public key B  E(M,B) Only Buffalo can read it using it private key b: E(b, E(M,B))  M In other words for any public/private key pair determined as previously shown, the encrypting function holds two properties: E(p, E(M,P))  M E(P, E(M,p))  M

6/28/20159 How can you authenticate “sender”? In real life you will use signatures: we will look at concept of digital signatures next. Instead of sending just a simple message, Atlanta will send a signed message signed by Atlanta’s private key: E(B,E(M,a)) Buffalo will first decrypt using its private key and use Atlanta’s public key to decrypt the signed message: E(b, E(B,E(M,a))  E(M,a) E(A,E(M,a))  M

6/28/ Digital Signatures Strong digital signatures are essential requirements of a secure system. These are needed to verify that a document is: Authentic : source Not forged : not fake Non-repudiable : The signer cannot credibly deny that the document was signed by them.

6/28/ Digest Functions Are functions generated to serve a signatures. Also called secure hash functions. It is message dependent. Only the Digest is encrypted using the private key.

6/28/ Alice’s bank account certificate 1.Certificate type:Account number 2.Name:Alice 3.Account: Certifying authority:Bob’s Bank 5.Signature:{Digest(field 2 + field 3)} K Bpriv

6/28/ Digital signatures with public keys

6/28/ Message Privacy Deals with confidentiality of messages. Message header has token and signature. Typically WS are chained together to form a complex service. In this situation we need end-to-end encryption schemes. Scheme such as SSL will not suffice. Solution: XML encryption allows for encryption of any combination of the message body, header, attachments, and sub-structures.

6/28/ XML Signature Service requestor encrypts the message and the signature information in the header it may specify in the header that it used providers public key. Private key of the provider is then used decrypt the XML request. XML Encryption allows for multiple keys to be used for encrypting different sections thus allowing intermediaries to access parts of the message.

6/28/ Message level Protection Message level protection has to with message integrity. How do assure that the message has not been modified? This is done by creating a message digest. Digest is a cryptographic checksum of an octet stream which is created using an algorithm, say, SHA-1 algorithm. Provider gets the message, its digest as signature and type of algorithm used to create the digest. It creates the digest and compares with the one from the sender and verifies the integrity of the messages.

6/28/ Message validity Message validity is ensuring that the contents of a message are appropriate to the service and that they are well formed. You check the types used and operations used are valid. SQL injection is a common malicious code. Typical identification method is to look for “;’ (semicolon) that allows for SQL commands to follow.

6/28/ Authentication Authentication is verifying that the requester is who he/she claims to be. In a typically closed environment: user name / password If the sender previously unknown: send credential to verify oneself. Trusted authorities issues certificates that can be used as credential. (Verified by Verisign)

6/28/ Authorization In any organization, data located may have levels of sensitivity. Ex: grades and student personal information in a university: Infosource at UB. Authorization is granting of rights which includes the granting of access based on access rights. This typically takes place after authentication. Three most common access control implementations: Access matrix Access Control List (ACL) Role Based Access Control (RBAC)

6/28/ Access Matrix A general model of access control as exercised by a file or database management system is that of an access matrix. Basic elements of the model are: Subject: An entity capable of accessing objects. The concept of subject equates that of a process. Object: Anything to which access is controlled. Ex: files, programs, segments of memory. Access right: The way in which an object is accesses by the subject. Examples: read, write, and execute.

6/28/ Access Matrix (contd.) userA userB userC File 1 File 2File 3 File 4 Acct1 Acct2 Printer1 Own R, W Own R, W Own R, W Own R, W R R WR Inquiry Credit Inquiry Credit Inquiry Debit Inquiry Debit P

6/28/ Access Matrix Details Row index corresponds to subjects and column index the objects. Entries in the cell represent the access privileges/rights. In practice, access matrix is quite sparse and is implemented as either access control lists (ACLs) or capability tickets.

6/28/ ACLs Access matrix can be decomposed by columns, yielding access control lists. For each object access control list lists the users and their permitted access rights. The access control list may also have a default or public entry to covers subjects that are not explicitly listed in the list. Elements of the list may include individual as well group of users.

6/28/ WS Security Access Control Scheme name/password access token associated with each process object indicating privileges associated with a user security descriptor access control list used to compare with access control list for object

6/28/ Access Token (per user/subject) Security ID (SID) Group SIDs Privileges Default Owner Default ACL

6/28/ Security Descriptor (per Object) Flags Owner System Access Control List (SACL) Discretionary Access Control List (DACL)

6/28/ Access Control List ACL Header ACE Header Access Mask SID ACE Header Access Mask SID......

6/28/ Access Mask Generic All Generic Execute Generic Write Generic Read Access System Security Maximum allowed Delete Read Control Write DAC Write Owner Synchronize Generic Access Types Standard Access Types Specific Access Types

6/28/ Access Control Using ACLs When a process attempts to access an object, the object manager in security executive reads the SID and group SIDs from the access token and scans down the object’s DACL. If a match is found in SID, then the corresponding ACE Access Mask provides the access rights available to the process.

6/28/ RBAC In 2004 the National Institute of Standards and Technology (NIST) published a standard for defining the features of the Role Based Access Control (RBAC). Two parts: (i) Reference model and (ii) System and Administrative functions. Reference model: objects, operations, permissions, roles and users (in-band artifacts) Administrative model: system functionality, administrative operations and reviews.

6/28/ RBAC Details RBAC starts with Permission sets. Permission express a privilege to access a resource. Examples of permission: “create a file”, “access grades information” (ublearns) Next steps is defines Roles and assigning permissions to Roles. Examples of roles: “Physician”, “Reviewer” Scenario driven approach is typically used to connect roles to permissions. Upper level ontology in SWS should map Users, Roles, Groups etc. to the ontology.