>Thanks again, but that brings up another question: Why is the PK stored in the Session rather than a property of a custom Identity object?

It's an implementation detail. As the developer of the app you never deal with the Session var directly and it's the storage mechanism that mm.Net uses to persist the login. Just having info in the Identity object does not persist the login information automatically (unless it's Windows Auth) and mm needs to use something to persist this non-system login.

Since mm has its own security mechanism there's not a lot of need to map to an underlying Security Principle, especially since the mm User objects expose a lot more functionality than the principle does. But just talking with Kevin we thought it might be a good idea to produce a principle object from the user object so if you already have security code in place you can just plop in the mm factory Principle and have it work as is.

You certainly wouldnt want mm to override the default principle because you might want to check security separately from the application security. In ASP.Net apps this happens frequently and in fact for MM you'll want to make sure of that so that you can lock down your main administration pages with Windows security since from there you can openly set permissions for everything else.