[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
David B. Nelson writes:
I think these would be some fairly special cases. Having the MAC address
of a user and his realm we may find out the CUI value. We can also ask
the user to get the value form his home institution. All this sounds
fairly clumsy, I agree. Perhaps it is not terribly useful, perhaps we
will go for a more complicated system of sending additional user
attributes by other means. I am not going to defend this user case too
strongly, time will show if it holds water.
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.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.