CSUN Identity Management

Middleware Analyst at Cal State Northridge's Information Technology Resources group, on the team that owned identity for the whole university — every student, every faculty member, every account, every login.

The work was enterprise daemons, and the surprising part in retrospect is what they were written in: OCaml. Not a fashionable choice in 2006 and not one now, but for long-running network daemons that must not fall over, a language with an honest type system and no null was doing something the industry took another decade to rediscover.

The single sign-on daemon

The piece I know best is the session daemon — an RPC server providing session-based authentication to web applications through browser cookies.

A login application verifies the user's credentials against the authentication service, then calls the daemon to open a session. The daemon caches the credentials and hands back an id string, which the login application sets as the user's cookie. No credential material is stored in that id — it is purely an index into the daemon's store, and the session is bound to the end user's apparent IP address.

Any other web application that needs to log the user into an external service reads the cookie, presents the id and the client IP to the daemon, and receives the credentials it needs. Every one of those calls requires the application to authenticate as well, with its own username and password, and each application is permitted only the specific daemon procedures it is authorized to call.

The rest of the estate

• An OpenLDAP-based identity management daemon, and the directory itself — a set of schemas describing what a person, a group, a department, and a college are in a university's terms, layered on the wider California State University person schema.

  Its published interface is the clearest statement of what identity management actually means at a university. Accounts can be created bare, from a template, or with a set of services attached; renamed; deleted. Affiliations — the relationships that make someone a student here, or staff, or both at once — can be listed, added, and removed independently of the account. Services get defined, described, and revoked as first-class objects, so entitlement is a thing you declare rather than a flag you set. Groups carry join and part policies, so whether you may add yourself to a group is a property of the group, not a question for whoever wrote the calling application.

  The error type is the part I would still defend. Rather than returning a status code, every operation returns one of an enumerated set of outcomes — no such user, user not unique, group membership invalid, cannot join, cannot part, managed group, affiliation invalid, status not allowed, permissions invalid — so a caller has to confront each way the operation can fail. That is the type system doing the work an English-language wiki page usually gets asked to do.

• An XML-RPC event handler daemon, so that changes to identity data could raise events other systems subscribed to, with a workflow for inspecting and reprocessing rejected events.

• An intrusion detection daemon, with its own configuration language and lexer.

• Java client libraries, generated over XML-RPC, so that Java applications could talk to the single sign-on and identity daemons without reimplementing the protocol — plus a Java group manager service.

The unglamorous half

I spent a lot of that job cleaning up the user directory to eliminate data redundancy, which is exactly as tedious as it sounds and exactly as necessary. A directory that has accumulated duplicate and contradictory records is one where nobody can answer "who is this person" with confidence, and everything built on top inherits the doubt.

I also led the web-based authentication project that hardened the university's portal login and forgot-password pages, and wrote log-parsing scripts that turned raw portal logs into usage statistics and, more usefully, into data-driven account lockout — letting the pattern of failed logins decide when an account should be secured rather than waiting for someone to notice.

Finally, I formalized the team's software development workflow and wrote down the department's standards. At twenty-two, on my first team of career engineers, that turned out to be the most transferable thing I did.