Multiuser Protection and the Mediator Pattern CSE432 02/22/2006 Matt Brenneke

Multiuser Protection Follow Unix design, user and other Users must have a login name Basic authentication, user must provide login name and password Follow unix design (again) 2 types of permissions for any node, those for the user, and those for other. We will address group later Treat User and login name the same, one to one mapping So how to we model a User? Using an object of course!

User Object Restrictions Clients can’t create User objects at will User object must always have a valid login name Client can’t instantiate a user w/o name and password These requirements push us towards a creational pattern at a minimum for the User object. We need a secure way to create the object, without exposing the Constructor to a client.

Creation Abstract Factory? No, Families of Objects Builder? No, different representation Factory Method? No, similar to Abstract Fact. Prototype? No, What, not How Singleton? Bingo! So lets look at the creational patterns. Abstract Factory focuses on families of objects, which we don’t have. Builder focuses on creating complex objects with the same interface and different representations Factory Method is to similar to Abstract Factory, without the focus on families Prototype focuses on what gets instantiated, now how it gets instantiated Singleton protects how the object gets created, and insures only one object is created at any given time.

Singleton - modified Authentication Multiple User objects Call Intantiate() logIn(), and add user and password parameters. Can return 0 if user or password is invalid Client can’t change logIn() by subclassing User Multiple User objects Keeps a hash of User objects Only one User object per username Patterns aren’t meant to domineer your design, just assist in it’s construction. We can change it! We need to add authentication to verify only valid users are created. Unlike a Constructor, logIn can return 0 if there is an invalid user or password By keeping our constructor private, a client can’t change the logIn process by just subclassing User. But the basic singleton pattern only allows one Instantiation of the object period. What about more than one user being given at a time?

Reading a file Before Now streamOut(ostream&); streamOut(ostream&, User*); Now when we read a file, we need to pass a user so the node can verify that the client has permission to read it Since creating a User object is protected, the Node can trust that any User object passed in is authentic. But having a client pass in the same User every time it accesses the filesystem can be a nuisance if the application is working on behalf of only one user.

Common case Give the user parameter a default value void streamOut(ostream&, const User* = 0); Add setUser and getUser functions to the User class static const User* User::getUser(); static void User::setUser(const User*); The login process for a user should call setUser once it has obtained a valid User object.

streamOut() changes Check for User* == 0 Call User::getUser() if true isReadable() -> isReadableBy(user) isReadableBy checks User->getLoginName against the Node’s owner. Node functions now must be modified to check if a User object was passed in. If one was passed in, use it, otherwise call the getUser function.

Groups? Groups have zero or more users. A user can be a member of zero or more groups. Glossed over the UNIX concept of groups earlier. Now it’s time to address them. Second item implies reference but not aggregation: Deleting a group does not delete its constituents.

Group Object Representation Composite? No Groups aren’t recursive A user might belong to several groups Don’t want to treat groups and users the same Mediator! Relationship between groups and nodes is complex and variable Needs loose coupling No groups of groups Not strictly hierachial Can’t log in as a group, don’t want to pass group objects around What can we use then? Mediator!

Mediator Overview Intent Encapsulate how a set of objects interact Promote loose coupling Allows you to vary interaction independently

Mediator Participants Interface for communicating with Colleagues ConcreteMediator (optional) Implements coordination between Colleagues Knows and maintains its Colleagues Colleague classes Knows its mediator class Communicates with Mediator only When colleagues work with only one mediator there is no reason to abstract the mediator class

Mediator Consequences Limits Subclassing Decouples Colleagues Simplifies object protocols Abstracts how objects cooperate Centralizes control May become monolithic itself Meidator pitfall is that it has a tendency towards monolithic Mediator classes.

Applied to Groups Users Groups Mediator Grouping Instead of a bunch of calls directly between users and groups, all interaction goes through the mediator Why user and not node?

Group Class members static getGrouping() static setGrouping(Grouping*, User*); register(User*,Group*,User*); unregister(User*, Group*, User*); getGroup(string, index); getUser(Group, index); Get and set groupings are static to allow mappings to be gloabally accessible and settable By replacing the Grouping object at run-time it’s possible to change the mapping in one move. setGrouping, register, and unregister are protected operations, so they must be called with an authorized User as their final argument Finally, getGroup and getUser identify associated groups and users.

Wrapping Up Chapter 2 Composite provides structure Proxy provides symlinks Visitor allows new, type specific functionality Template Method provided basic protection Singleton and Mediator combine to allow full Multi-user protection