It's bad security to volunteer ANYTHING about the security system. The conventional wisdom is that those who need to know should already know, and allowing those who don't to "fish" for potential points of attack shouldn't be an option.
I was unaware of it until just yesterday, but apparently, Tomcat6 did allow the admin app to discover roles, but Tomcat 7 removed that ability because "not all security Realms supported it". There is, in fact, no Realm API method to obtain roles, only to
test to see if a user is a participant.
I should also note that roles are not actually unique to a single app. If multiple apps are all participants in a single Realm - even if it isn't an SSO Realm - then the role namespace is common to all of them. So any given app might not employ all possible roles for the Realm. Also most Realms don't actually constraint role names, so you could define a rolename in the Realm's database (or equivalent) that might not currently be in use. Then there's the whole business with rolename remapping/aliasing.
There are times, of course, when knowing such things could be important. A sterling example would be a security administration function where you would setup user accounts and define their roles. However, it's really a lot safer not to make such a function an integral part of the application itself, but to instead make it a separate app. Which might not even be a webapp, as for example shops where they used Active Directory to manage security. In a complex enterprise, there's a lot of appeal for a Master Security Console to ride herd on users from an Enterprise perspective, instead of piecemeal. Especially since access to such an app could be limited to the Security group and/or authorized delegates.
