In this case, no. At least, not how I interpret the question. I guess I'll just spell it out (at the risk of invoking sidebar questions).
PrivilegedUser (authentication details only)
Profile (remainder of a user's "description")
(set_table_name = x or y or z)
Privilege (1 record per privilege)
Filter (1 record per data access filter definition)
Any one PrivilegedUser table record will be associated with one, and only one, of the Profile tables, and only one record in that Profile table. Any entry in the Profile table will be associated with one, and only one, of the PrivilegedUser table records. At any one time there is only ever one instance of a PrivilegedUser being used per request -- that being the logged in user.
This is for a group of applications where some of them have multiple user models in which profile details for one type of user is very different than another. Simple apps will need only one Profile, complex apps can have several. Profile tables could have a handful of fields or dozens of fields--of which none may be common, so it just doesn't make sense to use a single table. (Think doctors & patients, teachers & students -- both sharing the same login system, but vastly different user profiles because they use the app in very different ways).
I have used this system for quite some time already. The methodology is sound (and it's 90% written in Rails already), I'm just trying to figure out how to Railsify this and one other implementation detail.
At first I was wondering whether to try to handle it in PrivilegedUser or Profile, but the more I think about it, if it is possible to parameterize the has_one declaration in PrivilegedUser, I think that's what I'm looking for (which is how I handled it before), and I'll end up with a unique model per specific Profile (probably sub-classed ones, so I can consolidate common methods).