Object Oriented Analysis and Design Using the UML Architectural Design: Reuse and Security Mechanism OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 1 Will only go through first part – around 15 slides. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 2 Example: Reuse: Security Mechanism Here we are reverse engineering existing components into the Design Model and from Implementation Model. (Three reusable components – one is a GUI framework; other two support security on the server.) Packages in the system Representation of components being developed that Reused components might depend upon the in the Design Model from the Implementation security packages. Model UIFramework .dll GUI Framework ISecureUser (from Secure Interfaces) UserContext RemoteObject Your GUI Actual interface shown on ahead!!!! Your Entities <<subsystem>> Security Manager Secure.java A package - OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 3 Your Controllers Secure Interfaces Example: Reuse: Security Mechanism Referring to previous slide: The GUI Framework provides a standard set of user interface classes. This GUI Framework is “security aware” (note the dependency on the Secure User Interface). Any questions on the UML? Know the difference between a package and a subsystem??? OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 4 Referring to ‘Next’ Slide: For security, the UI provides a login screen that works with a server-side business object to create a user context. The server object will remain available to all server-based controllers for the duration of the session. DISCUSS! The Security Manager subsystem includes the classes that implement the ‘security behavior’ (e.g., create the ‘secure user context’). Package Secure Interfaces, supplies the security interfaces. Entries that are secure will realize an interface and provide a small set of behavior. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 5 Example: Reuse: Security Mechanism (1 of 4) Note where all these items are ‘from!!!’ MainApplicationForm This is a secure entry; “Realizes” the ISecureUser Interface. Secure User (not Data) : This shows how the securityrelated classes fit together. open() Again <<role>> stereotype is enterUserName() validateUserIDPassword() used to identify which classes are roles that should be enterPassword() 0..1 logInUser() developed by the designer as setupSecurityContext() they apply the mechanism. LoginForm (from GUI Framework) start() setupSecurityContext() 1 displayAvailOperations() 1 (from GUI Framework) 0..1 UserSecurityContext 0..1 SecurityAccess (from Security Manager) <<Interface>>0..1 ISecureUser setAccess() getAccess() getUserId() UserSecurityContext() checkInternalTables() (from Secure Interfaces) setAccess() getAccess() getUserId() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass (from Secure Interfaces) isReadable() isWriteable() isDeleteable() makeReadable() Note: all four of these makeWriteable() items are ‘from’ the makeDeleteable() Secure Interfaces new() package! (two are actually Interfaces to the package that must be realized. <<Interface>> ISecureData getUniqueId() OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved Note the multiplicities and composition and inheritance and dependencies! Discuss! For each application session, there must exist a class whose object realizes the ISecureUser Interface. (in our eg, the UserSecurityContext class). (In Java, we ‘implement’ this interface) The object manages information about the current user’s access to UniqueId (from Secure Interfaces) secure data without directly depending on the classes. generate() (ISecureUser classes depend on the asString() UniqueId() ISecureData interface, not on the actual secure data classes. (from Secure Interfaces) getUniqueID() getUserContext() getUserName() 6 Example: Reuse: Security Mechanism (2 of 4) LoginForm (from GUI Framework) MainApplicationForm (from GUI Framework) start() setupSecurityContext() 1 displayAvailOperations() 1 open() enterUserName() Secure User (still); validateUserIDPassword() enterPassword() Setting access rights. 0..1 logInUser() setupSecurityContext() getUserContext() The security system, via the getUserName() operations exposed in 0..1 0..1 UserSecurityContext (from Security Manager) <<Interface>>0..1 ISecureUser setAccess() getAccess() getUserId() UserSecurityContext() checkInternalTables() (from Secure Interfaces) SecurityAccess (from Secure Interfaces) isReadable() isWriteable() isDeleteable() makeReadable() makeWriteable() makeDeleteable() new() setAccess() getAccess() getUserId() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass UniqueId <<Interface>> ISecureData (from Secure Interfaces) generate() asString() UniqueId() (from Secure Interfaces) getUniqueID() getUniqueId() OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 7 ISecureUser, allows clients to set the access of the objects when they are created and check the access when they are manipulated at some later time. (Details on this are not shown.) There is one SecurityAccess instance per user login / session per secure object. Example: Reuse: Security Mechanism (3 of 4) LoginForm (from GUI Framework) MainApplicationForm (from GUI Framework) start() setupSecurityContext() 1 displayAvailOperations() 1 open() enterUserName() validateUserIDPassword() enterPassword() 0..1 logInUser() setupSecurityContext() getUserContext() getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) <<Interface>>0..1 ISecureUser setAccess() getAccess() getUserId() UserSecurityContext() checkInternalTables() (from Secure Interfaces) SecurityAccess isReadable() isWriteable() isDeleteable() makeReadable() makeWriteable() makeDeleteable() new() setAccess() getAccess() getUserId() new() UniqueId <<Interface>> ISecureData (from Secure Interfaces) generate() asString() UniqueId() (from Secure Interfaces) getUniqueID() getUniqueId() OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved MainApplicationForm keeps a reference to a ISecureUser obj until the form closes (this is represented by the composition relationship). (from Secure Interfaces) Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass Secure User: 8 The reference to the ISecureUser object actually comes back from the LoginForm, which creates the ISecureUser object upon successful logon (this is represented by the dependency relationship) Example: Reuse: Security Mechanism (4 of 4) LoginForm (from GUI Framework) MainApplicationForm (from GUI Framework) start() setupSecurityContext() 1 displayAvailOperations() 1 open() enterUserName() validateUserIDPassword() Classes can be made security aware by enterPassword() 0..1 realizing the ISecureData logInUser() setupSecurityContext() Interface and defining an getUserContext() attribute to hold a UniqueID. getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) <<Interface>>0..1 ISecureUser setAccess() getAccess() getUserId() UserSecurityContext() checkInternalTables() (from Secure Interfaces) SecurityAccess (from Secure Interfaces) isReadable() isWriteable() isDeleteable() makeReadable() makeWriteable() makeDeleteable() new() setAccess() getAccess() getUserId() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass UniqueId <<Interface>> ISecureData (from Secure Interfaces) generate() asString() UniqueId() (from Secure Interfaces) getUniqueID() getUniqueId() OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved Secure Data: 9 The UniqueID class makes sure that all users and all pieces of data from all different applications get their own unique ids. All classes that have been mapped to the Security analysis mechanism should realize the ISecureData interface. (one object per class will do this…) Example: Security Mechanism: Secure User Set-Up at Login Any User : MainApplicationForm : LoginForm : ISecureUser 1. start( ) 1.1. open( ) 2. enterUserName( ) We did not expand on validation since it was a reverse engineered component 3. enterPassword( ) 4. logInUser( ) 4.1. validateUserIDPassword( ) 4.2.1. new(UserID) [ login successful ] 5.1. getUserContext( ) The MainApplicationForm retains the secure user context for later processing by the user. The ISecureUser is passed to each form that is opened. This form in turn passes it into each controller that starts up. This is propagated to the remote controllers that use the ISecureUser to set and check privileges. 6. close( ) 7. displayAvailOperations( ) Display the operations/functions that the application OOAD Using the UML - Appendix: Security Mechanism, v 4.2 provides. Copyright 1999 Rational Software, all rights reserved The LoginForm will – upon successful login – create an instance of ISecureUser (physically an instance of UserSecurityContext). GO THROUGH SEQUENCE DIAGRAM… THEN NOTE for the next slide: [ login successful ] 4.2. setupSecurityContext( ) 5. setupSecurityContext( ) As mentioned earlier, for each application session, there must exist an object whose class realizes the ISecureUser Interface. This object manages information about the current user’s access to secure data. 10 (The setting up of a user context is described in more detail for the Course Registration System example in the Use Case Design module where the Login use-case realization is discussed. ) Example: Security Mechanism: Secure User Propagation :SampleMain AppForm : SampleAppSubForm : SampleController : User It is assumed that the User has logged in. 1: // doSomething( ) 2: open(ISecureUser) Secure user session was set up during Login All entries that need to perform access checks must have access to the current user’s session (i.e., have access to ISecureUser). This example shows how a sub-form and the associated controller are provided access to the secure user session. Provide secure user session to controller for any later validation 3: new() 4: setSession(ISecureUser) 5: // display available operations( ) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 11 The secure user session is established during login and maintained by the main application form. The secure user session is then propagated from the main application form to any sub-forms and supporting controllers (note the use of ISecureUser as a parameter to the open command, as well as the new setSession() operation). Example: Security Mechanism: Secure Object Access Secure Data again! Secure Object Client : ISecureUser All classes that have been mapped to the Security analysis mechanism should : realize the ISecureData Interface. All SecurityAccess classes that must verify the access of some secure data should do so via the ISecureUser interface. 1: getAccess(ISecureData) There will be one object whose class realizes the ISecureUser interface per Student session. 2: isReadable( ) When retrieving secure data, the client must verify the current user’s ability to access the data, using the security access information for the current user. AND/OR 3: isWriteable( ) AND/OR 4: isDeleteable( ) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 12 Specifically, in the example, after retrieving an object that realizes the ISecureData interface, the Secure Object Client must retrieve the security access info for the secure object for the current user and compare them to make sure that the current user can view/edit/delete the object. Incorporating the Security Mechanism: Steps (Italicized text describes the architectural decisions made with regards to JDBC for our Course Registration example We need to: Provide access to the class libraries needed to implement the Security mechanism (for reuse, etc.) New Security package will be created to contain the classes that implement the security mechanism. Note: Package containing forms dependent on Security GUI Framework package OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 13 (continued) Incorporating the Security Mechanism: Steps (Italicized text describes the architectural decisions made with regards to JDBC for our Course Registration example. Create main application forms: • Establish main application forms, with associated login forms • For each application that is to be developed, a main application form needs to be defined. • In some cases, such a main form may have already been identified. If not, one needs to be defined now. In any case, the main application form must be inherited from the MainApplicationForm provided in the GUI Frameworks package. • You may need to create sub-forms to support the individual functions/operations provided by the application. If any Login forms were identified in analysis, these need to be replaced with the LoginForm provided in the GUI Frameworks package. This LoginForm will be associated and ‘driven by’ the MainApplicationForm defined above via mechanisms provided in the GUI Frameworks package. In Architectural Design, we make sure that the necessary package relationships exist, but the creation of the main application forms has been deferred until detailed design (e.g., Use Case and Subsystem OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Design). 14 Copyright 1999 Rational Software, all rights reserved (continued) Incorporating the Security Mechanism: Steps (Italicized text describes the architectural decisions made with regards to JDBC for our Course Registration example. Package containing core data types dependent on Security Secure Interfaces package • All classes that need to be secure must realize the ISecureData interface in the Secure Interfaces package. The necessary package relationships will be added here, but the introduction of all of the individual realization relationships (for all data that is to be secure) will be deferred until detailed design (e.g. Use Case and Subsystem Design). Add realization relationships • Have all secure classes realize the ISecureData interface OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 15 (continued) Incorporating the Security Mechanism: Steps (contd) Provide secure user session (ISecureUser) access, where necessary Package containing control classes dependent on Security GUI Framework package Deferred Control classes will need secure user session access Add setSession(ISecureIUser) operation All entities that need to perform access checks must have access to the current user’s session (i.e., have access to ISecureUser). This means that you may need to add ISecureUser as a parameter to some operations. For the Course Registration System, the control classes will need access to the secure user session, so a setSession(ISecureUser) operation needs to be added to each control class. The modification of the individual control classes has been deferred until detailed design (e.g., Use-Case and Subsystem Design). OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 16 Incorporating the Security Mechanism: Steps (contd) Create/update interaction diagrams with security processing Secure user set-up (login) Secure user propagation (secure user session Deferred availability) Secure data access (checking access permissions) In order to make sure that everything has been accounted for in the system, interaction diagrams should be defined which model the added security functionality. Specifically, secure user set-up (including Login, as well as making sure that the secure user session is made available to all entities that will need to perform security checks) and secure data access (includes checking a user’s permission before providing access to secure data). The actual incorporation of the mechanism is deferred until detailed design (e.g., UseCase Design and Subsystem Design). At this point, the architect provides guidance to the designers and makes sure that the architecture has the necessary infrastructure to support the mechanism (i.e., has the necessary packages and package relationships). OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 17 Example: Incorporating the Security Mechanism: Steps (1 of 2) <<boundary>> LoginForm <<boundary>> Sample Application Form // login user() // enter username and password() // validate username and password() LoginForm MainApplicationForm (from GUI Framework) (from GUI Framework) 0..1 start() setupSecurityContext() 1 open() enterUserName() validateUserIDPassword() enterPassword() logInUser() setupSecurityContext() getUserContext() Sample Secure Class SampleSecureClass getUniqueID() <<control>> Sample Control Class <<control>> Sample Control Class setSession(toUser: ISecureUser) ISecureDat (fromaSecure Interfaces) This is an example of some of the changes described on the previous slide that must be 1 made to the Course Registration Model to incorporate the Security mechanism: . The LoginForm from the security GUI Framework will replace the LoginForm identified 0..1 in UC Analysis . The MainApplicationForm from the security GUI framework will be used as the basis <<boundary>> Sample Application Form for new app main forms that will serve as the context for the forms identified in UC Analysis. Application Main forms will be created for each of the major system actors. This is because the functionality in each of these applications is disjoint. The actual definition of the main application forms has been deferred until detailed design OOAD Using the UML - Appendix: Security Mechanism, v 4.2 18 Copyright 1999 Rational Software, all rights reserved (e.g. Use Case and Subsystem Design) Sample Main Form Example: Incorporating the Security Mechanism: Steps (2 of 2) <<boundary>> LoginForm <<boundary>> Sample Application Form // login user() // enter username and password() // validate username and password() Sample Secure Class <<control>> Sample Control Class LoginForm (from GUI Framework) MainApplicationForm 0..1 (from GUI Framework) 1 start() setupSecurityContext() SampleSecureClass open() enterUserName() validateUserIDPassword() enterPassword() logInUser() setupSecurityContext() getUserContext() getUniqueID() <<control>> Sample Control Class setSession(toUser: ISecureUser) ISecureData Sample Main Form (from Secure Interfaces) Any classes that must be secure will need to realize the ISecureData interface. This involves implementing the getUniqueID() operatiion. The actual definition of the individual realization relationships (one for each class that is to be secure) 0..1 has been deferred until detailed design (e.g. Use Case and Subsystem Design). <<boundary>> The control classes will need access to the secure user session, so a Sample Application Form setSession(ISecureUser) operation needs to be added to each control class. The modification of the individual control classes has been deferred until detailed design (e.g. Use Case and Subsystem Design). 1 OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 19 Example: Incorporating the Security Mechanism: Steps (contd) Sample Application Package Security GUI Framework <<subsystem>> Security Manager Sample Secure Data Secure Interfaces The above demonstrates the package dependencies needed to support the changes described on the previous slides to incorporate the security mechanism: The design elements that support the security mechanism have been placed in a single package, Security. The package(s) that contains the application main forms (in the above example, the Sample Application package) will have a dependency on the Security GUI Framework package. The package(s) that contains the classes that need to be secure (in the above example, the Sample Secure Data package) will have a dependency on the Security Secure Interfaces package. The package(s) that contains the classes that will need to access the secure classes (in the above example, the Sample Application package) will have a dependency on the Security Secure Interfaces package. Specific application and core abstraction packages are defined in the next section. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 20 Use-Case Design Slides The following slides can be inserted during the Use-Case Design module – to address the Security considerations. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 21 Review: Incorporating the Security Mechanism: Steps This represents a summary of the steps first discussed in Architectural Design that can be used to implement the security mechanism talked about. Italicized text – architectural decisions made with regards to JDBC for our example. The check marks indicate what steps have been completed. Let’s continue to incorporate this mechanism. In Architectural Design, a new Security mechanism was created to contain the classes that implement the security mechanism. Provide access to the class libraries needed to implement the Security mechanism New Security package – created to contain classes that implement the security mechanism. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 22 (continued) We know that for each application to be developed, a main application form needs to be defined. In our example, The main application form must inherit from the MainApplicationForm provided in GUI Frameworks package. Sub-forms may be needed to create to support the individual functions/operations provided by the application. Establish main application forms, with associated login forms Package containing forms dependent on Security GUI Framework package Create main application forms OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 23 Review: Incorporating the Security Mechanism: Steps If any existing Login forms were identified in analysis, these need to be replaced with the LoginForm provided in the GUI Frameworks package. This LoginForm will be associated and ‘driven by’ the MainApplicationForm defined above via mechanisms provided in the GUI Frameworks package. In architectural design, we put the infrastructure in place, now the actual main application forms will need to be created. All classes that need to be secured must realize the ISecureData interface in the Secure Interfaces package. In Arcdhitectural Design, access to the interface was provided; now we must add the actual realizes relationships. Have all secure classes realize the ISecureData interface Package containing core data types dependent on Security Secure Interfaces package Add realization relationships OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 24 (continued) Review: Incorporating the Security Mechanism: Steps (contd) •All entities that need to perform access checks must have access to the current user’s session (i.e., have access to ISecureUser). This means that you may need to add ISecureUser as a parameter to some operations. For the Course Registration System, the control classes will need access to the secure user session, so a setSession(ISecureUser) operation needs to be added to each control class. In Architectural Design, the package and package dependencies were put into place. Now, update the control classes so that they have access to the secure user session. Provide secure user session (ISecureUser) access, where necessary Package containing control classes dependent on Security GUI Framework package Control classes will need secure user session access Add setSession(ISecureIUser) operation OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 25 Review: Incorporating the Security Mechanism: Steps (contd) In order to make sure that everything has been accounted for in the system, interaction diagrams should be defined which model the added security functionality. Specifically, secure user set-up (including Login, as well as making sure that the secure user session is made available to all entities that will need to perform security checks) and secure data access (includes checking a user’s permission before providing access to secure data). These interaction diagrams will now be developed. Create/update interaction diagrams with security processing Secure user set-up (login) Secure user propagation (secure user session availability) Secure data access (checking access permissions) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 26 - Done Example: Incorporating the Security Mechanism <<boundary>> LoginForm <<boundary>> RegisterForCoursesForm // register for courses() // login user() // enter username and password() // validate username and password() MainApplicationForm (from GUI Framework) LoginForm <<entity>> Schedule (from GUI Framework) 1 0..1 start() setupSecurityContext() MainStudentForm <<entity>> Schedule open() enterUserName() validateUserIDPassword() enterPassword() logInUser() setupSecurityContext() getUserContext() <<control>> RegistrationController <<control>> RegistrationController setSession(toUser: ISecureUser) ISecureData (from Secure Interfaces) This is an example of some of the changes described on the previous slide that were 1 made to the Course Registration Model to incorporate the Security mechanism. The LoginForm from the security GUI framework will replace the LoginForm identified in Use-Case Analysis. The MainApplicationForm from the security GUI framework will 0..1 be used as the basis for the new MainStudentForm. TheMainStudentForm will <<boundary>> RegisterForCoursesForm inherit from the MainApplicationForm). Thus, the MainStudentForm will be “securityaware”. The original RegisterForCoursesForm will now be a subform of the new MainStudentForm. The Schedule class must be secure, so it will realize the // register for courses() ISecureData interface. The RegistrationController control classes will need access to the secure user session, so a setSession(ISecureUser) operation will be added. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 27 Example: Incorporating the Security Mechanism (contd) <<layer>> Application <<layer>> Application Registration <<layer>> Business Services <<layer>> Business Services University Artifacts (from Business Services) Security (from Business Services) Secure Interfaces (from Security) GUI Framework (from Security) This demonstrates the packages dependencies needed to support the changes described on the previous slides to incorporate the security mechanism. (Packages and associated relationships are defined in Architectural Design. This is a review slide. The design elements that support the security mechanism will be placed in a single package, Security. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 28 Example: Incorporating the Security Mechanism (contd) <<layer>> Application <<layer>> Application Registration <<layer>> Business Services University Artifacts (from Business Services) <<layer>> Business Services Security (from Business Services) Secure Interfaces (from Security) GUI Framework (from Security) The Application package(s) that contains the application main forms will have a dependency on the Security GUI Framework package (for the main and form definitions). For the course registration application, that package is the Application package. The Application package(s) that contains the control classes will have a dependency on the Security Secure OOAD Using the package UML - Appendix: Security v 4.2 Interfaces (for theMechanism, ISecureUser definition). For the course registration application, that package is the 29 Copyright 1999 Rational Software, all rights reserved Application package. Example: Incorporating the Security Mechanism (contd) <<layer>> Application <<layer>> Application Registration <<layer>> Business Services <<layer>> Business Services University Artifacts (from Business Services) Security (from Business Services) Secure Interfaces (from Security) GUI Framework (from Security) The University Artifacts package contains the classes that need to be secure, so it will have a dependency on the Security Secure Interfaces package. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 30 Example: Incorporating the Security Mechanism: Secure User Set-Up In order to use the security features of the system, the secure user session must be established. This occurs during login. Any User : MainStudentForm : LoginForm StudentSession : ISecureUser 1. start( ) 1.1. open( ) The security mechanism provides a main application form and a login form, which will replace the original login form. The user name for students is the Student ID. 2. enterUserName( ) 3. enterPassword( ) 4. logInUser( ) The above example is the design usecase realization for the Login use case. 4.1. validateUserIDPassword( ) [ login successful ] 4.2. setupSecurityContext( ) It is almost completely re-written from Use-Case Analysis. 4.2.1. new(UserID) [ login successful ] 5. setupSecurityContext( ) 5.1. getUserContext( ) The MainStudentForm retains the Student's session for later processing by the user. 6. getUserName( ) 7. close( ) 8. displayAvailOperations( ) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 31 Display the operations/functions that the application provides. Example: Incorporating the Security Mechanism: Secure User Propagation The above is a fragment of the : MainStudentForm Register for Courses : RegistrationController : Student use-case realization interaction diagram. : RegisterForCoursesForm It is assumed that the Student has logged in. See Basic Flow - Login Interaction diagram. It demonstrates how the created1: // register for courses( ) 2: open(ISecureUser) secure user session is provided to the Secure user session was set up during Login 3: // is registration open?( ) RegisterForCoursesForm and the RegistrationController. This [registration is open] is necessary because in our 4: new() system, the controllers will be 5: setSession(ISecureUser) performing the security checks. The user may select any of these operations 6: // display available operations( ) 7: // create schedule( ) 8: // update schedule( ) 9: // delete schedule( ) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 32 Provide secure user session to controller for any later validation The sequence diagram fragment (next slide) from the Register for Courses use-case realization follows. It demonstrates the interactions that need to be added when the application creates secure data (specifically, a Student’s Schedule). After creating the Student’s Schedule, the RegistrationController sets the security access information for the Schedule for the current Student. Since the Student is the “owner” of the schedule, he/she is given full access. The access permissions are maintained in the SecureUser that is managed by the MainApplicationForm (the MainStudentForm, in the case of Register for Courses). See the Login sequence diagram on an earlier slide. The RegisterForCoursesForm is provided with the SecureUser when it is opened by the MainStudentForm. As stated earlier, the Schedule class was mapped to the Security analysis mechanism, so it realizes the SecureData interface. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 33 Example: Incorporating the Security Mechanism: Secure Data Access : RegisterForCoursesForm : RegistrationController : SecurityAccess : ISecureUser : Schedule : Student 1: // select 4 primary and 2 alternate offerings( ) 2: // create schedule with offerings( ) 3: // create with offerings( ) 4: new( ) 5: makeReadable( ) 6: makeWriteable( ) Set the access permissions to wide open for the Student/owner of the Schedule 7: makeDeleteable( ) 8: setAccess(ISecureData, SecurityAccess) 9: // add schedule(Schedule) At this, point the Submit Schedule subflow is executed. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 34 : Student This next sequence diagram is a subset of the View of Participating Classes (VOPC) for the Register for Courses use-case realization. It contains the classes for the instances in the previous interaction diagrams (i.e., the classes affected by the incorporation of the security mechanism). Notice the addition of SecureData, SecurityAccess and ISecureUser and their relationships with the application classes. The incorporation of the security processing has been localized to the controllers, in addition to the secure classes realizing the secure interface. Any forms “get security for free” if they inherit from the View class provided with the GUI Frameworks. Note: the display of most of the operations and attributes have been suppressed for clarity of the diagram. However, a few selected operations that demonstrate the security mechanism have been shown. OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 35 Example: Incorporating the Security Mechanism: VOPC <<Interface>> ISecureUser MainApplicationForm (from GUI Framework) (from Secure Interfaces) 1 0..1 MainStudentForm View (from Registration) (from GUI Framework) open(forUser : ISecureUser) 1 <<Interface>> ISecureData (from Secure Interfaces) 0..1 <<boundary>> RegisterForCoursesForm (from Registration) 1 <<control>> RegistrationController SecurityAccess (from Registration) (from Secure Interfaces) 1 setSession(forUser : ISecureUser) 0..1 0..1 +currentSchedule 0..1 <<entity>> Schedule (from University Artifacts) 0..* 0..1 +registrant 1 <<entity>> Student (from University Artifacts) OOAD Using the UML - Appendix: Security Mechanism, v 4.2 Copyright 1999 Rational Software, all rights reserved 36