Creating A Consent System
Internet2 – a consortium of US colleges and universities --
had received a grant to create a “consent” system that was appropriate
for the intricacies of the higher education environment.
A higher education institution holds a lot of sensitive personal
information about its students, staff and faculty. The institution
typically wants to offer its users some control over the release of
their personal information, but just how much control depends on the
receiving party, the user’s role, and other possibly complex factors.
No one within the Internet2 community of architects had come up with an
architecture that could address this situation.
In this particular case, I already knew a lot about the identity management
stores, policies, and procedures in higher education, so I could get to work
on a solution without interviewing subject matter experts.
Here are the steps I took:
- Fact Finding: Reviewed the characteristics of existing consent systems,
particularly one that had modest traction in higher education.
Assessed what was working well, and also not so well.
- Architecture Drafting: Considered what could be a better fit in terms
of functionality -- one that allowed for both institutional policies
and user policies on personal information to be considered --
and came up with a draft architecture.
- Internal Testing of the architecture: Drew diagrams of the flows
between components that addressed the existing use cases.
- Documenting the architecture: After seeing that the draft architecture
“worked,” wrote up a document detailing the architecture, policies,
and functionality it supported. In this document, discussed how this
new consent system fit in with an existing popular identity management system.
- Soliciting Feedback: Sent the architecture document to an Internet2 “Scalable
Consent Team” consisting of multiple architects, developers, and project managers.
Created additional diagrams to further help analysis and understanding.
In this particular case, the feedback helped to refine the presentation of the
architecture. The architecture itself stood up to all challenges.
- Moving Beyond the architecture: After the architecture won approval,
created a policy language that allows for fine grained control of
when an institutional policy “wins” and when the user’s policy does.
This architecture and the policy language are being implemented and rolled out by a
major research university as part of its identity and access management infrastructure;
the grant organization (NSTIC) is delighted, as is Internet2. You can learn more about CAR here: Internet2 CAR Website
Simplifying Administration Of Identity
A major research university with multiple overlapping identity stores had a
cumbersome and inefficient means of assigning identifiers to “new” users,
resulting in hours of manual labor each week as identity administrators sought
to sort out which users were truly new and which were existing users.
- Fact Finding: Interviewed identity administrators, SMEs on the identity
stores (database programmers and Java programmers), and end users
(themselves administrators). Quickly developed a deep understanding of
the existing systems and processes.
- Architecture Drafting: Architected a system of small, reusable services
for finding people and assigning identifiers. Further, architected an
identity de-duplication app that used the small services to greatly
streamline the identity administrator's tasks.
- Documenting the architecture and the app: created a set of diagrams
and text descriptions for the architecture. Did the same for the app,
plus created screen mockups
- Soliciting Feedback: created and gave slide presentations on the architecture
and what it addressed. Provided “demos” of the app via the screen mockups.
Did slight revisions to both based on the feedback (e.g. adding a “work notes”
section to the identity de-duplication app).
The identity administrators were delighted with the de-duplication system I designed.
This system awaits development. A variant of the system I architected for finding people
and assigning identifiers was deployed in 2016 and remains a core part of the identity
and access management infrastructure for the university.
Security For A Mobile Phone App With A Social Networking Component
A startup creating a mobile coupon app with reward points and a social networking
component was unsure about how to protect customer data from both outsiders and insiders.
It was also unclear about how to model an “account” given that a customer could have multiple
phones, could change phones, etc. Proposals from the company’s own engineers weren’t cutting it.
- Fact Finding: Interviewed the director of engineering about their existing client-server
design, and what they wanted for the future. Also, reviewed an existing security
proposal from an internal engineer.
- Solution Drafting: Created a clear model of users, accounts, and phones.
Provided design and implementation recommendations to help enforce the model and protect
both client and server resources. The recommendations covered authentication, authorization,
cryptographic keys in support of authentication, and life-cycle management of users and keys.
- Documenting & Soliciting Feedback: Detailed the account model, design recommendations and
implementation recommendations in a series of emails and phone calls with the director of engineering.
“Marlena was exactly what we needed during the initial development of our service and mobile application.
She asked a lot of penetrating questions, forced us to confront some of our assumptions, and
led us to a much more secure product.” - Andy Affleck Director of Engineering, Ozmott LLC
Engagement period: 10 hours.