1. CSE298 CSE300 OV-1.1 CSE333 Development of an RBAC Framework for Distributed XML-Data Presentation of Semester Project in CSE333: Distributed Component Systems Instructor: Dr. S. Demurjian by Yiqing Ju, Jan Boysen & Christian Slamka April 26 th, 20044

2. CSE298 CSE300 OV-1.2 CSE333Overview  Chris  Last semester’s work  Use cases  Model  Yiqing  Technologies  SOAP  SAAJ/JAX-RPC  Jan  Components  Sequence Diagrams

3. CSE298 CSE300 OV-1.3 CSE333 Scenario of last semester’s work  Suppose you have data in XML-format, e.g. data about patients in a hospital  Users (e.g. nurses) want to have access to this data  Problem: Not every user should be able to access all elements in the XML-file, only distinct ones  Solution: Role Based Access Control  Approach: assigning each element in the XML- file a security level, e.g. “1 - Top secret”, “4 – unclassified”

4. CSE298 CSE300 OV-1.4 CSE333 Security files  Results in three kinds of security files (in XML- format): 1. Application-security: definition of security- level of each element, eventually time- constraints 2. Role-security: definition of roles, their security-levels and time-constraints 3. User-security: definition of users, their security-levels and role assignments

5. CSE298 CSE300 OV-1.5 CSE333 Example: Role-Security XML-file ”In charge of patients in department 4, section 2” unlimited ”In charge of patients in department 3, section 7” 11/23/1999 to 12/31/2004

6. CSE298 CSE300 OV-1.6 CSE333 Developed applications  Using single data-/security-repository (in this case a directory-/file structure)  Prototype of two applications: 1. Administration application (Chris)  For security-file-administration (e.g. adding users, assigning security-levels to each element) 2. Viewer application (Charles)  Filters the application data according to which user logs on with which role; also checks eventual time-constraints

7. CSE298 CSE300 OV-1.7 CSE333 Use Case of current project

8. CSE298 CSE300 OV-1.8 CSE333 Model chosen

9. CSE298 CSE300 OV-1.9 CSE333 2 nd possible model

10. CSE298 CSE300 OV-1.10 CSE333 Explanation of model  The application data as well as the security data (all in XML-format) are distributed over the domains in the system.  Every domain has a role for communication with other domains  There are two stages of RBAC-control: 1. User-stage: the user has a certain role and tries to retrieve the desired data 2. Domain-stage: the domain itself has a role which it has gotten from another domain to access its data on behalf of user

11. CSE298 CSE300 OV-1.11 CSE333 Explanation of model  Access to another domain’s data only can be achieved by using the user’s “own” domain user has to be assigned to a user has to be assigned to a“home”-domain  The elements a user can access from another domain are determined by the intersection of: 1. the elements the domain can access in the other domain 2. the elements the user can access within his domain.

12. CSE298 CSE300 OV-1.12 CSE333 Technologies - SOAP  Simple Object Access Protocol.  SOAP is the technology we use for our application’s inter-domain communication.  The reasons for choosing SOAP are as follows: A)In our application, the application data and the security-constraint files are all stored in XML format. SOAP provides a simple and lightweight mechanism for exchanging XML data over the Internet. B)SOAP is both language and platform independent because it is in XML syntax.

13. CSE298 CSE300 OV-1.13 CSE333 SOAP Structures  The Envelope must be the first element in any SOAP message.  After the Envelope, a SOAP message can contain an Optional Header element.  The Body element is the area of a SOAP message where the application- specific data is placed. (*The Body element must be in XML format)

14. CSE298 CSE300 OV-1.14 CSE333 SOAP Message <SOAP:Envelope xmlns:SOAP='http://schemas.xmlsoap.org/soap/envel ope/' SOAP:encodingStyle='http://schemas.xmlsoap.org/so ap/encoding/'' <SOAP:Body><GetData> 123456 123456 <appName>hospital</appName><domainRole>1</domainRole><domain>192.168.0.101</domain></GetData></SOAP:Body></SOAP:Envelope>

15. CSE298 CSE300 OV-1.15 CSE333 SOAP Transport  SOAP messages do not dictate either a transport or a convention.  However the majority of the SOAP messages are sent over HTTP.  The HTTP request-response model matches up with SOAP.  SOAP requests are transported in the body of a POST or M-POST, and the SOAP response is returned in the HTTP response  In request, the Content-Type header must indicate that the body is "text/xml" for a SOAP message..

16. CSE298 CSE300 OV-1.16 CSE333 SOAP Request POST /sample/services/data/data.asp HTTP/1.1 Host: 192.168.0.101 Content-Type: text/xml Content-Length: nnn SOAPAction: "http://192.168.0.101/GetData" <S:Envelope = xmlns:S='http://schemas.xmlsoap.org/soap/envelope/' S:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> S:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> 123456 123456 hospital hospital 1 1 192.168.0.101 192.168.0.101 </S:Envelope>

17. CSE298 CSE300 OV-1.17 CSE333 SOAP Response HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 31 Jan 2001 07:21:19 GMT MessageType: CallResponse Content-Length: nnn Content-Type: text/xml Expires: Wed, 31 Jan 2001 07:21:20 GMT Cache-control: private <Env:Envelope xmlns:Env="http://schemas.xmlsoap.org/soap/envelope/" Env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Nothing Serious Nothing Serious </Env:Envelope>

18. CSE298 CSE300 OV-1.18 CSE333SAAJ  SOAP with Attachments API for Java  A powerful API for JAVA developers writing SOAP messaging applications.  Based on the SOAP 1.1 and SOAP with Attachments specifications.  Provides a standard way to send XML documents over the Internet from the Java platform.

19. CSE298 CSE300 OV-1.19 CSE333 A Sample SAAJ Code MessageFactory factory = MessageFactory.newInstance(); SOAPMessage message = factory.createMessage(); The message created in the preceding line of code, will automatically have the following: <SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body></SOAP-ENV:Body></SOAP-ENV:Envelope>

20. CSE298 CSE300 OV-1.20 CSE333JAX-RPC  Java API for XML-based RPC  A JAVA API for building web services and clients that use remote procedure calls (RPC) and XML.  In JAX-RPC, a remote procedure call is represented by an XML-based protocol such as SOAP.  JAX-RPC does a lot of behind-the-scene jobs that SAAJ users must do by themselves  Compared with SAAJ, JAX-RPC is easier to be implemented while SAAJ still requires a lot more work on coding and more understanding of XML structures.  However SAAJ gives the users more control on manipulating the SOAP messages elements

21. CSE298 CSE300 OV-1.21 CSE333 JAX-RPC Endpoint Interface  In JAX-RPC, a server side web service is created by simply building a service endpoint interface and its implementation class. A simple service endpoint interface can be as simple as the following: import java.rmi.Remote; import java.rmi.RemoteException; import java.rmi.RemoteException; public interface MySample extends Remote { public interface MySample extends Remote { public String GetData(String informationID, public String GetData(String informationID, String appName, String appName, String domainRole, String domainRole, String domain) String domain) throws RemoteException; throws RemoteException; }

22. CSE298 CSE300 OV-1.22 CSE333 JAX-RPC Endpoint Implementation Class  A simple service endpoint implementation class can be as simple as the following: public class MyImplementation implements MySample { public String GetData(String informationID, public String GetData(String informationID, String appName, String appName, String domainRole, String domain) String domainRole, String domain) System.out.print(informationID); System.out.print(informationID);}

23. CSE298 CSE300 OV-1.23 CSE333 Engineering Part  What functionallity is needed to build such a system?  Component Diagram  How do theses components interact which each other?  Sequence Diagram  Intra-domain Request  Outgoing inter-domain Request  Incoming inter-domain Request

24. CSE298 CSE300 OV-1.24 CSE333Components  Data-Storage  Application Data  RBAC Data  Network Components  User Interface  SOAP Server  SOAP Client  Inter-Domain Authentication  Core/XML Filter

25. CSE298 CSE300 OV-1.25 CSE333Data-Storage  Application Data  All data belong to an appliation  RBAC Data  User-Information  userID, name, passwd, security-level, time- constrains  Role-Information  Role-name, security-level, time-constraints  Security Constrains  application data, security constraints, user-role mapping  All data are stored in the XML-format

26. CSE298 CSE300 OV-1.26 CSE333 Network Components  User Interface.  Server which listens to incoming requests from users of this domain.  E.g. Webserver, Java-Application, etc.  Communication Interface between the user and the main application.  Provides a set of functions the user can call/invoke.  getPatientData(), updatePatientData(), etc.  SOAP Server.  Listens to incoming inter-domain requests of other domains.  Provides a set of function similar to the ones in the user-interface.

27. CSE298 CSE300 OV-1.27 CSE333 Network Components  SOAP Client  Sends user requests to other domains  Calls a function provided by a SOAP Server of another domain  Uses the domain role NOT the user role  Interdomain Authentication  Digital Signatures for Domain Authentication  Every incoming SOAP request is verified  Every outgoing SOAP request is signed

28. CSE298 CSE300 OV-1.28 CSE333 Core/XML Data Filter  Core/XML Data Filter  Heart of the system  Controls the communication between the components  Filters the Application Data in respect to the users role

29. CSE298 CSE300 OV-1.29 CSE333 Component Diagram

30. CSE298 CSE300 OV-1.30 CSE333 Intra-Domain Request User 1.Data- Request 2.Data-Request 3.Get Security Data 4. Get Application Data 5. Filtered Data 6.Filtered data

31. CSE298 CSE300 OV-1.31 CSE333 Inter-Domain Request [outgoing] User 1.Data- Request 9. Filtered data 2.Data-Request 8. Filtered Data 3. Get Security Data 4.Data-Request 7. Application Data 5. Sign 6. Send Inter-domain Request

32. CSE298 CSE300 OV-1.32 CSE333 Inter-Domain Request [incoming] 2. Verify Request 4.Get Security Data 3.Data-Request 6. Filtered Data 7. Send filtered Data 1.Data- Request 5. Get Application Data