One way to address (1) could be to enable any _method_, that MIGHT be configured to _require_ *prioir* ext auth, to have an additional keyno field, in the method call (and wire format). If said keyno value is not default, the read acl associated with Key[keyno] would be evaluated. Said acl could require that the same key (now as principal) be currently logged in, in order to read the key. The acl for the key would be managed as today. Keys used in this manner (to provide method-level role-based access control) might be specified in the constructor, or in the format command.
Design-stage comments?
I had an lazy/unprofessional notion also - to use the presence of the keyno in the 'other' acl associated with Key[keyno] as a configuration signal - requiring that any method subject to read-time controls now protect the method's results, using said key (using some process).
I thinking also of requiring that the keys in Key[] are ordered - checked with manufacturing/format time controls - with all ext.auth keys being earlier in the array than any type of Key instance.
My only qualm with these minimialist-style changes is that we are really not upgrading for the entire range of the real problem being addressed : 2 and n-factor authentication requirements, to acess a method (or object). For example, a host driver might be required to complete ext-auth, the CO might be required to bio-authentication, and the user shall be required to present the old pin, during user pin update. _______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
