To get the roles, the code you originally posted will work nicely, I'd think.
However, I'm a bit confused about this statement:
...but it would be nice to read the roles of a user as well without having to assign some permission key to each role for identification.
This seems to suggest that you are conceptualizing that roles should be used to determine access to some feature in your application. This is not the case. Permissions are intended to be used to control access. This makes sense once you work it out. Permissions have an action (GRANT, READONLY, DENY) that determine access, while roles are simply containers for permissions. Thus the permission determines what access, while the role simply allows a set of permissions to be assigned to a user at once. Also, since multiple roles might use the same permission, with conflicting actions (i.e. one role might have an action of GRANT for a permission and another the action of DENY) AND the user might be directly assigned a permission, the SF RBS enforces the rules related to this (see help for more details). The GetPermission() method sorts all that out and returns the final verdict for any permission. In code, or via the SecurityKey setting in forms or BOs, you then set the security key that controls access to a feature. I hope that this makes sense (if it didn't already).
Of course, there could be many reasons you might also want to access the roles assigned to a user and for those uses, the SFS BOs are how you'd do it (and how you
are doing it). And you don't have to assign permissions to a role for this to work. I.e. you can create empty roles (with no permissions assigned to the role) and then assign users to them. Also note that the RBS system is designed to allow the end users to create users, create roles and assign users to roles/permissions, unless you disable that feature. So, there could be roles you don't know about out in the field.
Hope that helps. If not, keep asking!
