> First, and most important for Turbine, Principals are > where Roles and Groups would be implemented. > > Second, and also important for Turbine, Permissions are > connected to Principals, not directly to subjects. > > Third, the Subject would have many Principals, one of > which serves as the userid. > > Fourth, Principals come into play in Pluggable > Authentication Modules (PAM). This allows an > administrator of an application to choose their own > authentication technologies and policies. (LDAP, DB, > ActiveDirectory, Kerberos,...) > > Fifth, Principals are used to enable a Subject to login > once and be granted access to many applications.
I'm very thick-headed... Can you provide a blow by blow example of these concepts? Something like "User U1 has Principals P1 and P2, which in turn...", etc., but hopefully with names for each entity that are from a real-life requirement? > +-------+ 1 N +---------+ 1 N +----------+ > |Subject+-------+Principal+----------+Permission| > +-------+ +----+----+ +----------+ > | > +-----------+---------+ > | | | > +--+---+ +--+--+ +-+--+ > |UserId| |Group| |Role| > +------+ +-----+ +----+ Shouldn't Role be changed into Project, as per your other messages? > -Eric -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
