Sample Technical Requirements
Mark Bruhn, then Chief Security Officer at Indiana University, developed the following list of possible technical requirements for authentication while at one of the NMI-EDIT workshops:
- Open source and/standards compliant - there are too many different operating systems to get locked into a proprietary solution
- Well-supported
- High availability/reliability
- Scaleable to >150,000 principals
- Not burdensome supporting <5000 principals
- Multi-factor: plug-in locally-determined methods
- Logging – minimally, the date, time, source IP, username, remote logging (e.g., to loghost)
- No password passing; or at least strong encryption of the password in transit
- Passwords not stored at all, or at least stored one-way encrypted
- Facility for users to change their own passwords; forces various formatting requirements
- Facility for users to change their own passwords, if they don’t know the old password
- Opportunity to configure with password expiration, history, and intruder lockout
- Authentication protocol should an open standard
- Facility for managing users, passwords, and associated metadata, both by people and by other systems
- Authentication should be two-way: Client-to-Service, Service-to-Client
- Support separate authentication zones with configurable trust relationships
- Both the authentication and management services should provide clear APIs