His comment about it turning into 500 lines of code isn't an exaggeration, most likely. The truth is that it's so simple that one can hardly understand why anyone uses ACLs after you've implemented something like this. You create a series of functions that define the attributes you are interested in, there's some lightweight context maintenance, then in the core of the system (the "500 lines") you simply tie all the pieces together in accordance with the business rules. It's so simple it almost boggles the mind. Bog-standard refactoring will get you there in nothing flat, and of course you have full Turing-complete language constructs at your disposal.

One hint: Write the code in a functional style, i.e., Haskell style. Pass in the full context to the permission function. For instance, if you have a time-sensitive function, don't have the time-sensitive function call the system clock; have it extract the time from the context your provided. If you call the system clock, you'll never be able to write the tests you're going to need to write. Similarly for many things, like direct LDAP access or whatnot. The internal permission code needs to be a pure function. Fortunately, that doesn't make it any harder to write, even in an OO-based language.

If you want to get really slick because your context has multiple expensive operations like direct LDAP access (although this is a bad idea if you're going to be calling this frequently), you can even create two context implementations, one for testing that simply returns provided values and one that lazily goes out and gets LDAP data or whatever if you need it. Best of all worlds that way.

Thanks. Nice to have a sketch of the thing's structure. It's a finite state machine, where the 'attributes' are the states, and the code is the transition rule.

Test harnesses for this -- hm.