On 11/8/2013 5:25 AM, Stian Thorgersen wrote:
I'm going about default roles wrongly both in terms of
implementation and UI. I'm well aware of that. This was only a temporary solution. The
main reason why the default roles are added directly to the token instead of when users
are registered is to make it easy to add applications after a user has initially
registered. Again, I didn't intend it to remain like that for long. I wanted something
simple and functional while we discuss and implement a proper solution.
The temp solution should change to automatically adding default roles to
a user on registration. The UI should change to what we want in the
future, a registration UI page much like role mapping UI. Initially,
behind the scenes it would manipulate default roles, but when composite
roles available it should switch to that.
I like the idea of having a "REGISTRATION" composite role.
Just to clarify, the registration composite role should be expanded when a user is
registered, and the user would be granted the roles it is composed of (not the actual
registration composite role itself). That would allow you to revoke roles from specific
users later. This would also mean that if you change the registration composite role the
changes would not be reflected in already registered users. To resolve this I think we
should allow composite roles to contain composite roles themselves. This means that a
developer could create a "DEFAULT" composite role, and add it to the
"REGISTRATION" composite role. The "DEFAULT" composite role would be
expanded when we're creating the token, not when the user is registered.
+1.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com