3. Promoting the user access rights. A positive example,
for a change. Suppose we gave an official guest at the
university and we want to provide him with some extra
services. CUI will allow us to place the user in a special
VLAN and allow printing, for instance. This is a lot
easier then creating a local account and setting up the
user access based on that.
You're going to set up a local "shadow" user authorization database, keyed
on CUI values, to add, remove and modify user access permissions? Hmmm.
Good luck managing that. You potentially have no way to link the real user
identity to a CUI at the remote site, but you think it can be useful for
creating a supplementary authorization service? I can foresee all sorts of
operational problems with such a scheme. As I say, good luck with that. I
see no direct conflict with RADIUS services or attributes. It's just that
sometimes CUI can only be related to a specific session, and its
packet-level behaviors, and not to a person.