Object Oriented Analysis and Design Using the UML OOADv4.2 Instructor Notes Object Oriented Analysis and Design Using the UML Architectural Design: Reuse and Security Mechanism Appendix - Security Mechanism

Will only go through first part – around 15 slides.

Example: Reuse: Security Mechanism OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism Here we are reverse engineering existing components into the Implementation and Design Model. (Three reusable components – one is a GUI framework; the other two support security on the server.) This slide demonstrates Reuse by applying reverse engineering. Reverse-engineering existing components can give you a bag of tricks to pull from. Components were defined in the Introduction to Object Orientation module. A subsystem is the design representation of a component. They both encapsulate a set of replaceable behaviors behind one or more interfaces. In this course, we will concentrate on the impact on the Design Model. The Implementation Model is out of the scope of the OOAD course. This slide, becomes more clear once the remaining security slides have been presented. “Secure” entities need to know how to implement the ISecureData interface; therefore they depend on SecureInterfaces. Controllers will work with ISecureUser (residing down in SecureInterfaces) to set the security attributes of new objects and check the security of objects that are being manipulated; therefore, their package is shown as depending on ISecureUser. The GUI framework includes the LoginForm and MainApplicationForm that depend on the ISecureUser interface, so must depend on the SecureInterfaces package. Packages in the system being developed that might depend upon the security packages. Representation of components in the Design Model Reused components from the Implementation Model GUI Framework UIFramework .dll Your GUI ISecureUser (from Secure Interfaces) Your Controllers Actual interface shown on ahead!!!! <<subsystem>> Security Manager UserContext RemoteObject Your Entities Secure.java Secure Interfaces A package - Appendix - Security Mechanism

Example: Reuse: Security Mechanism OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism  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).  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. This slide demonstrates Reuse by applying reverse engineering. Reverse-engineering existing components can give you a bag of tricks to pull from. Components were defined in the Introduction to Object Orientation module. A subsystem is the design representation of a component. They both encapsulate a set of replaceable behaviors behind one or more interfaces. In this course, we will concentrate on the impact on the Design Model. The Implementation Model is out of the scope of the OOAD course. This slide, becomes more clear once the remaining security slides have been presented. “Secure” entities need to know how to implement the ISecureData interface; therefore they depend on SecureInterfaces. Controllers will work with ISecureUser (residing down in SecureInterfaces) to set the security attributes of new objects and check the security of objects that are being manipulated; therefore, their package is shown as depending on ISecureUser. The GUI framework includes the LoginForm and MainApplicationForm that depend on the ISecureUser interface, so must depend on the SecureInterfaces package. GUI Framework UIFramework .dll Your GUI ISecureUser (from Secure Interfaces) Your Controllers Actual interface shown on next slide!!!! UserContext RemoteObject <<subsystem>> Security Manager Your Entities Secure.java GUI Framework and Secure Interfaces are packages. Secure Interfaces Appendix - Security Mechanism

Example: Reuse: Security Mechanism (1 of 4) OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism (1 of 4) Note where all these items are ‘from!!!’ Secure User (not Data) : LoginForm (from GUI Framework) This shows how the security- related classes fit together. Again <<role>> stereotype is used to identify which classes are roles that should be developed by the designer as they apply the mechanism. Note the multiplicities and composition and inheritance and dependencies! Discuss! MainApplicationForm (from GUI Framework) Do not spend too much time on this slide. Just walk through the basics (as described in the Student Notes). Stay at a fairly high level. Some of this may be more clear to the students when they see the interaction diagrams provided on the next few slides. The classes to be replaced by concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals). There is no need for a separate ISecureData.SetUniqueID operation, as the ISecureData.GetUniqueID creates a unique id if one does not exist. The reverse engineered security mechanism is actually a lightweight framework. You can make a big production out of the power of interfaces in supporting a framework view wherein a set of security classes written for a previous project end up working with your classes to provide this service. "So now our controllers are calling this security class asking if the current user has read access to the timecard, and they are passing the timecard in as a parameter. As long as the timecard implements the ISecureData interface, the security class is perfectly happy.” Note: Composition is shown for the LoginForm because that was reverse-engineered. Whether the other aggregation relationships should be composition or not will be addressed in the Class Design module. This is a secure entry; “Realizes” the ISecureUser Interface. open() enterUserName() validateUserIDPassword() start() enterPassword() setupSecurityContext() 1 0..1 logInUser() displayAvailOperations() setupSecurityContext() 1 getUserContext() getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) SecurityAccess (from Secure Interfaces) <<Interface>> 0..1 ISecureUser (from Secure Interfaces) isReadable() setAccess() isWriteable() For each application session, there must exist an class whose object realizes the ISecureUser Interface. (in our eg, the UserSecurityContext class). The object manages information about the current user’s access to secure data without directly depending on the classes. (ISecureUser classes depend on the ISecureData interface, not on the actual secure data classes. getAccess() setAccess() isDeleteable() getUserId() getAccess() Note: all four of these items are ‘from’ the Secure Interfaces package! (two are actually Interfaces to the package that must be realized. makeReadable() UserSecurityContext() getUserId() makeWriteable() checkInternalTables() new() makeDeleteable() new() Role to be filled by the designer applying the mechanism UniqueId (from Secure Interfaces) <<role>> SampleSecureClass <<Interface>> ISecureData (from Secure Interfaces) generate() asString() getUniqueID() UniqueId() getUniqueId() Appendix - Security Mechanism

Example: Reuse: Security Mechanism (2 of 4) OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism (2 of 4) LoginForm (from GUI Framework) MainApplicationForm (from GUI Framework) Do not spend too much time on this slide. Just walk through the basics (as described in the Student Notes). Stay at a fairly high level. Some of this may be more clear to the students when they see the interaction diagrams provided on the next few slides. The classes to be replaced by concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals). There is no need for a separate ISecureData.SetUniqueID operation, as the ISecureData.GetUniqueID creates a unique id if one does not exist. The reverse engineered security mechanism is actually a lightweight framework. You can make a big production out of the power of interfaces in supporting a framework view wherein a set of security classes written for a previous project end up working with your classes to provide this service. "So now our controllers are calling this security class asking if the current user has read access to the timecard, and they are passing the timecard in as a parameter. As long as the timecard implements the ISecureData interface, the security class is perfectly happy.” Note: Composition is shown for the LoginForm because that was reverse-engineered. Whether the other aggregation relationships should be composition or not will be addressed in the Class Design module. open() enterUserName() Secure User (still); Setting access rights. validateUserIDPassword() start() enterPassword() setupSecurityContext() 1 0..1 logInUser() displayAvailOperations() setupSecurityContext() 1 getUserContext() The security system, via the operations exposed in 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. getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) SecurityAccess (from Secure Interfaces) <<Interface>> 0..1 ISecureUser (from Secure Interfaces) isReadable() setAccess() isWriteable() getAccess() setAccess() isDeleteable() getUserId() getAccess() makeReadable() UserSecurityContext() getUserId() makeWriteable() checkInternalTables() new() makeDeleteable() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass UniqueId (from Secure Interfaces) <<Interface>> ISecureData (from Secure Interfaces) generate() getUniqueID() asString() getUniqueId() UniqueId() Appendix - Security Mechanism

Example: Reuse: Security Mechanism (3 of 4) OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism (3 of 4) LoginForm (from GUI Framework) Secure User: MainApplicationForm (from GUI Framework) Do not spend too much time on this slide. Just walk through the basics (as described in the Student Notes). Stay at a fairly high level. Some of this may be more clear to the students when they see the interaction diagrams provided on the next few slides. The classes to be replaced by concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals). There is no need for a separate ISecureData.SetUniqueID operation, as the ISecureData.GetUniqueID creates a unique id if one does not exist. The reverse engineered security mechanism is actually a lightweight framework. You can make a big production out of the power of interfaces in supporting a framework view wherein a set of security classes written for a previous project end up working with your classes to provide this service. "So now our controllers are calling this security class asking if the current user has read access to the timecard, and they are passing the timecard in as a parameter. As long as the timecard implements the ISecureData interface, the security class is perfectly happy.” Note: Composition is shown for the LoginForm because that was reverse-engineered. Whether the other aggregation relationships should be composition or not will be addressed in the Class Design module. open() enterUserName() MainApplicationForm keeps a reference to a ISecureUser obj until the form closes (this is represented by the composition relationship). 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) validateUserIDPassword() start() enterPassword() setupSecurityContext() 1 0..1 logInUser() displayAvailOperations() setupSecurityContext() 1 getUserContext() getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) SecurityAccess (from Secure Interfaces) <<Interface>> 0..1 ISecureUser (from Secure Interfaces) isReadable() setAccess() isWriteable() getAccess() setAccess() isDeleteable() getUserId() getAccess() makeReadable() UserSecurityContext() getUserId() makeWriteable() checkInternalTables() new() makeDeleteable() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass UniqueId (from Secure Interfaces) <<Interface>> ISecureData (from Secure Interfaces) generate() getUniqueID() asString() getUniqueId() UniqueId() Appendix - Security Mechanism

Example: Reuse: Security Mechanism (4 of 4) OOADv4.2 Instructor Notes Example: Reuse: Security Mechanism (4 of 4) LoginForm (from GUI Framework) Secure Data: MainApplicationForm (from GUI Framework) Do not spend too much time on this slide. Just walk through the basics (as described in the Student Notes). Stay at a fairly high level. Some of this may be more clear to the students when they see the interaction diagrams provided on the next few slides. The classes to be replaced by concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals). There is no need for a separate ISecureData.SetUniqueID operation, as the ISecureData.GetUniqueID creates a unique id if one does not exist. The reverse engineered security mechanism is actually a lightweight framework. You can make a big production out of the power of interfaces in supporting a framework view wherein a set of security classes written for a previous project end up working with your classes to provide this service. "So now our controllers are calling this security class asking if the current user has read access to the timecard, and they are passing the timecard in as a parameter. As long as the timecard implements the ISecureData interface, the security class is perfectly happy.” Note: Composition is shown for the LoginForm because that was reverse-engineered. Whether the other aggregation relationships should be composition or not will be addressed in the Class Design module. open() enterUserName() Classes can be made security aware by realizing the ISecureData Interface and defining an attribute to hold a UniqueID. 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…) validateUserIDPassword() start() enterPassword() setupSecurityContext() 1 0..1 logInUser() displayAvailOperations() setupSecurityContext() 1 getUserContext() getUserName() 0..1 0..1 UserSecurityContext (from Security Manager) SecurityAccess (from Secure Interfaces) <<Interface>> 0..1 ISecureUser (from Secure Interfaces) isReadable() setAccess() isWriteable() getAccess() setAccess() isDeleteable() getUserId() getAccess() makeReadable() UserSecurityContext() getUserId() makeWriteable() checkInternalTables() new() makeDeleteable() new() Role to be filled by the designer applying the mechanism <<role>> SampleSecureClass UniqueId (from Secure Interfaces) <<Interface>> ISecureData (from Secure Interfaces) generate() getUniqueID() getUniqueId() asString() UniqueId() Appendix - Security Mechanism

Example: Security Mechanism: Secure User Set-Up at Login OOADv4.2 Instructor Notes Example: Security Mechanism: Secure User Set-Up at Login Any User : : LoginForm : ISecureUser 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. 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:  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. (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. ) MainApplicationForm Message 5 may seem like It comes out of nowhere because the SomeUser actor is independently active while the windows go through their flow of control. If you disregard steps 2, 3, 4, then nothing looks strange; it is obvious that step 5 is just the thing the MainApplicationForm does after step 1.1. Message 4.2.1 is an oversimplification. You can’t create an ISecureUser object just be sending a new() message. The creation of a new instance involves some sort of a factory that creates and instance of the class that realizes the interface. In the case of the ISecureUser interface, such an object exists on the server, so the distribution mechanism would need to be involved. Distribution is discussed in more detail in the Describe Distribution module. LoginForm retains control until it reaches some concept of completion of the task which does not yet remove the window from memory. 1. start( ) 1.1. open( ) 2. enterUserName( ) We did not expand on 3. enterPassword( ) validation since it was a reverse engineered 4. logInUser( ) component 4.1. validateUserIDPassword( ) [ login successful ]  4.2. setupSecurityContext( ) 4.2.1. new(UserID) [ login successful ] The 5. setupSecurityContext( ) MainApplicationForm retains the secure user context for later 5.1. getUserContext( ) processing by the user. 6. close( ) 7. displayAvailOperations( ) Display the operations/functions that the application provides. Appendix - Security Mechanism

Example: Security Mechanism: Secure User Propagation OOADv4.2 Instructor Notes Example: Security Mechanism: Secure User Propagation 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. 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). :SampleMain AppForm : : The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). SampleAppSubForm SampleController : User It is assumed that the User has logged in. Secure user session was 1: // doSomething( ) set up during Login Provide secure user session to controller for any later validation 2: open(ISecureUser) 3: new() 4: setSession(ISecureUser) 5: // display available operations( ) Appendix - Security Mechanism

Example: Security Mechanism: Secure Object Access OOADv4.2 Instructor Notes Example: Security Mechanism: Secure Object Access Secure Data again! All classes that have been mapped to the Security analysis mechanism should realize the ISecureData Interface. All classes that must verify the access of some secure data should do so via the ISecureUser interface. There will be one object whose class realizes the ISecureUser interface per Student session. 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. 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. When a secure object is created, access for it must be set for the current user. Usually, this is full access for the current user, read-only for others. Only a retrieve example was provided for scoping reasons. The classes to be replaced by concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals). Secure Object : ISecureUser : Client SecurityAccess 1: getAccess(ISecureData) 2: isReadable( ) AND/OR 3: isWriteable( ) AND/OR 4: isDeleteable( ) Appendix - Security Mechanism

Incorporating the Security Mechanism: Steps OOADv4.2 Instructor Notes Incorporating the Security Mechanism: Steps (Italicized text describes the architectural decisions made with regards to JDBC for our Course Registration example Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Remind the students that the actual design of this mechanism is deferred until detailed design. At this point, we just want to make sure that the architecture can handle the incorporation of the security mechanism (i.e., that the infrastructure is in place). 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 (continued) Appendix - Security Mechanism

Incorporating the Security Mechanism: Steps OOADv4.2 Instructor Notes 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 Design). Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Remind the students that the actual design of this mechanism is deferred until detailed design. At this point, we just want to make sure that the architecture can handle the incorporation of the security mechanism (i.e., that the infrastructure is in place). (continued) Appendix - Security Mechanism

Incorporating the Security Mechanism: Steps OOADv4.2 Instructor Notes 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 Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Remind the students that the actual design of this mechanism is deferred until detailed design. At this point, we just want to make sure that the architecture can handle the incorporation of the security mechanism (i.e., that the infrastructure is in place). (continued) Appendix - Security Mechanism

Incorporating the Security Mechanism: Steps (contd) OOADv4.2 Instructor Notes Incorporating the Security Mechanism: Steps (contd) 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 In many cases, the interaction diagrams developed in analysis can be “matured” to include the new classes and interactions required to support security. However, try to maintain the readability of the diagrams. Separate diagrams may need to be created. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Deferred 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). Appendix - Security Mechanism

Incorporating the Security Mechanism: Steps (contd) OOADv4.2 Instructor Notes Incorporating the Security Mechanism: Steps (contd) 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) In many cases, the interaction diagrams developed in analysis can be “matured” to include the new classes and interactions required to support security. However, try to maintain the readability of the diagrams. Separate diagrams may need to be created. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Deferred 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., Use-Case 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). Appendix - Security Mechanism

OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism: Steps (1 of 2) LoginForm // login user() // enter username and password() // validate username and password() <<boundary>> Sample Application Form <<boundary>> Sample Secure Class Sample Control Class <<control>> MainApplicationForm (from GUI Framework) LoginForm (from GUI Framework) SampleSecureClass Sample Control Class <<control>> setSession(toUser: ISecureUser) 0..1 open() getUniqueID() start() 1 setupSecurityContext() enterUserName() validateUserIDPassword() enterPassword() ISecureData (from Secure Interfaces) logInUser() setupSecurityContext() Sample Main Form getUserContext() This is an example of some of the changes described on the previous slide that must be made to the Course Registration Model to incorporate the Security mechanism: . The LoginForm from the security GUI Framework will replace the LoginForm identified in UC Analysis . The MainApplicationForm from the security GUI framework will be used as the basis 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 (e.g. Use Case and Subsystem Design) 1 0..1 Sample Application Form <<boundary>> Appendix - Security Mechanism

OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism: Steps (2 of 2) LoginForm // login user() // enter username and password() // validate username and password() <<boundary>> Sample Application Form <<boundary>> Sample Secure Class Sample Control Class <<control>> LoginForm (from GUI Framework) Sample Control Class <<control>> setSession(toUser: ISecureUser) MainApplicationForm (from GUI Framework) SampleSecureClass 0..1 open() 1 enterUserName() getUniqueID() start() validateUserIDPassword() setupSecurityContext() enterPassword() logInUser() ISecureData (from Secure Interfaces) setupSecurityContext() getUserContext() Sample Main Form 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) has been deferred until detailed design (e.g. Use Case and Subsystem Design). 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). 1 0..1 Sample Application Form <<boundary>> Appendix - Security Mechanism

Example: Incorporating the Security Mechanism: Steps (contd) OOADv4.2 Instructor Notes 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. Appendix - Security Mechanism

OOADv4.2 Instructor Notes Use-Case Design Slides Note: If your students are interested in the Security mechanism, these slides should be inserted while presenting incorporation of the the security mechanism in the Use-Case Design module. The following slides can be inserted during the Use-Case Design module – to address the Security considerations. Appendix - Security Mechanism

Review: Incorporating the Security Mechanism: Steps OOADv4.2 Instructor Notes 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. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. The check marks indicate what steps have been completed. Remind the students that the actual design of this mechanism is deferred until detailed design. At this point, we just want to make sure that the architecture can handle the incorporation of the security mechanism (i.e., that the infrastructure is in place). (continued) Appendix - Security Mechanism

Establish main application forms, with associated login forms 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

Review: Incorporating the Security Mechanism: Steps OOADv4.2 Instructor Notes 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. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. The check marks indicate what steps have been completed. Remind the students that the actual design of this mechanism is deferred until detailed design. At this point, we just want to make sure that the architecture can handle the incorporation of the security mechanism (i.e., that the infrastructure is in place). Have all secure classes realize the ISecureData interface Package containing core data types dependent on Security Secure Interfaces package Add realization relationships (continued) Appendix - Security Mechanism

Review: Incorporating the Security Mechanism: Steps (contd) OOADv4.2 Instructor Notes 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 In many cases, the interaction diagrams developed in analysis can be “matured” to include the new classes and interactions required to support security. However, try to maintain the readability of the diagrams. Separate diagrams may need to be created. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Appendix - Security Mechanism

Review: Incorporating the Security Mechanism: Steps (contd) OOADv4.2 Instructor Notes 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) In many cases, the interaction diagrams developed in analysis can be “matured” to include the new classes and interactions required to support security. However, try to maintain the readability of the diagrams. Separate diagrams may need to be created. Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals. Ö - Done Appendix - Security Mechanism

OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism LoginForm // login user() // enter username and password() // validate username and password() <<boundary>> Schedule <<entity>> RegistrationController <<control>> RegisterForCoursesForm // register for courses() <<boundary>> The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). LoginForm (from GUI Framework) Schedule <<entity>> MainApplicationForm (from GUI Framework) RegistrationController <<control>> setSession(toUser: ISecureUser) 1 0..1 open() start() enterUserName() setupSecurityContext() validateUserIDPassword() ISecureData (from Secure Interfaces) enterPassword() logInUser() setupSecurityContext() MainStudentForm getUserContext() This is an example of some of the changes described on the previous slide that were 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 be used as the basis for the new MainStudentForm. TheMainStudentForm will inherit from the MainApplicationForm). Thus, the MainStudentForm will be “security-aware”. The original RegisterForCoursesForm will now be a subform of the new MainStudentForm. The Schedule class must be secure, so it will realize the ISecureData interface. The RegistrationController control classes will need access to the secure user session, so a setSession(ISecureUser) operation will be added. 1 0..1 <<boundary>> RegisterForCoursesForm // register for courses() Appendix - Security Mechanism

Example: Incorporating the Security Mechanism (contd) OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism (contd) <<layer>> Application Registration <<layer>> The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). It is also possible to have security mechanisms in both the Application layer and the Business Services layer, with the Application layer security mechanisms dependent on the Business Services layer security mechanisms. The Application layer mechanisms would provide security that was aware of application-specific access rules (e.g. a person requires security level X to perform a specific transaction) while the Business Services layer mechanism would simply provide a generic way to define transactions and security access restrictions and to enforce those restrictions. The Business Services layer stuff is highly re-usable across applications, but there may be some application-specific aspects to handling security. Thus, there can actually be mechanisms at both levels. This information is provided FYI only. This is not the approach we took in this course. Application <<layer>> Business Services <<layer>> Business Services Security (from Business Services) University Artifacts (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. Appendix - Security Mechanism

Example: Incorporating the Security Mechanism (contd) OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism (contd) <<layer>> Application Registration <<layer>> The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). It is also possible to have security mechanisms in both the Application layer and the Business Services layer, with the Application layer security mechanisms dependent on the Business Services layer security mechanisms. The Application layer mechanisms would provide security that was aware of application-specific access rules (e.g. a person requires security level X to perform a specific transaction) while the Business Services layer mechanism would simply provide a generic way to define transactions and security access restrictions and to enforce those restrictions. The Business Services layer stuff is highly re-usable across applications, but there may be some application-specific aspects to handling security. Thus, there can actually be mechanisms at both levels. This information is provided FYI only. This is not the approach we took in this course. Application <<layer>> Business Services <<layer>> Business Services Security (from Business Services) University Artifacts (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 Interfaces package (for the ISecureUser definition). For the course registration application, that package is the Application package. Appendix - Security Mechanism

Example: Incorporating the Security Mechanism (contd) OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism (contd) <<layer>> Application Registration <<layer>> The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). It is also possible to have security mechanisms in both the Application layer and the Business Services layer, with the Application layer security mechanisms dependent on the Business Services layer security mechanisms. The Application layer mechanisms would provide security that was aware of application-specific access rules (e.g. a person requires security level X to perform a specific transaction) while the Business Services layer mechanism would simply provide a generic way to define transactions and security access restrictions and to enforce those restrictions. The Business Services layer stuff is highly re-usable across applications, but there may be some application-specific aspects to handling security. Thus, there can actually be mechanisms at both levels. This information is provided FYI only. This is not the approach we took in this course. Application <<layer>> Business Services <<layer>> Business Services Security (from Business Services) University Artifacts (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. Appendix - Security Mechanism

Example: Incorporating the Security Mechanism: Secure User Set-Up OOADv4.2 Instructor Notes 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. The security mechanism provides a main application form and a login form, which will replace the original login form. The above example is the design use-case realization for the Login use case. It is almost completely re-written from Use-Case Analysis. Any User : MainStudentForm : LoginForm StudentSession : The items in yellow were added/utilized as part of incorporating the security mechanism (but this does not show up in the black and white manuals). ISecureUser 1. start( ) 1.1. open( ) The user name for students is the Student ID. 2. enterUserName( ) 3. enterPassword( ) 4. logInUser( ) 4.1. validateUserIDPassword( ) [ login successful ] 4.2. setupSecurityContext( ) 4.2.1. new(UserID) [ login successful ] 5. setupSecurityContext( ) The MainStudentForm 5.1. getUserContext( ) retains the Student's session for later processing by the user. 6. getUserName( ) 7. close( ) 8. displayAvailOperations( ) Display the operations/functions that the application provides. Appendix - Security Mechanism

Example: Incorporating the Security Mechanism: Secure User Propagation OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism: Secure User Propagation The above is a fragment of the Register for Courses use-case realization interaction diagram. It demonstrates how the created secure user session is provided to the RegisterForCoursesForm and the RegistrationController. This is necessary because in our system, the controllers will be performing the security checks. : : : MainStudentForm RegisterForCoursesForm RegistrationController Note: On the presented slide, the items that were added/utilized as part of incorporating the mechanism are shown in yellow, but this does not show up in the back-and-white manuals. : Student It is assumed that the Student has logged in. Secure user See Basic Flow - Login Interaction diagram. session was 1: // register for courses( ) set up during Login 2: open(ISecureUser) 3: // is registration open?( ) [registration is open] Provide secure user session to controller for any later validation 4: new() 5: setSession(ISecureUser) The user may select any of these operations 6: // display available operations( ) 7: // create schedule( ) 8: // update schedule( ) 9: // delete schedule( ) Appendix - Security Mechanism

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.

Example: Incorporating the Security Mechanism: Secure Data Access OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism: Secure Data Access : RegisterForCoursesForm : RegistrationController : : ISecureUser : Schedule : Student SecurityAccess Note: On the presented slide, the items that were added/utilized as part of incorporating the mechanism are shown in yellow, but this does not show up in the back-and-white manuals. : Student 1: // select 4 primary and 2 alternate offerings( ) 2: // create schedule with offerings( ) 3: // create with offerings( ) 4: new( ) 5: makeReadable( ) Set the access permissions to wide open 6: makeWriteable( ) 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. Appendix - Security Mechanism

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.

Example: Incorporating the Security Mechanism: VOPC OOADv4.2 Instructor Notes Example: Incorporating the Security Mechanism: VOPC <<Interface>> MainApplicationForm ISecureUser (from GUI Framework) (from Secure Interfaces) Note: On the presented slide, the items that were added/utilized as part of incorporating the mechanism are shown in yellow, but this does not show up in the back-and-white manuals. 1 0..1 MainStudentForm View (from Registration) (from GUI Framework) 1 open(forUser : ISecureUser) <<Interface>> ISecureData 0..1 (from Secure Interfaces) <<control>> <<boundary>> RegistrationController SecurityAccess RegisterForCoursesForm (from Registration) (from Secure Interfaces) (from Registration) 1 1 setSession(forUser : ISecureUser) 0..1 0..1 +currentSchedule <<entity>> Schedule 0..1 (from University Artifacts) 0..* 0..1 1 +registrant <<entity>> Student (from University Artifacts) Appendix - Security Mechanism