P
Peter Judge
Guest
In 11.1 and up (the .1 is *very* important) managing this stuff becomes much easier. You can set up an authentication system that uses the _User table, and associate that with a domain. A domain seems to be what your groupID is. So yes, I would implement domains. One of the design goals of the OE implementation is that you can switch the domains' authentication system at runtime (ie if you move from _User to your own db tables). The user would log in with credentials like username@groupid and provide a password. The domain (groupID) would know which authentication system to use (_User) and would authenticate based on that. The user session would be asserted and you would have a C-P to work with. There's a session with a basic overview of the Identity management flow at pugchallenge.org/downloads.html (session 233). Direct link is pugchallenge.org/.../233_Basics_of_IM.pptx . This session talks about much of this stuff, and uses an application db table for user credentials. Using the C-P for authorisation requires some more work and thought on your part. The C-P has a ROLES property as well as some custom properties that you can use for this stuff. Note that once the C-P is sealed (ie on successsful login) you cannot change those values. I also did a session on some of these aspects at the same PCA (session #361; pugchallenge.org/.../361_Coding_with_IM.pptx ) which may provide some guidelines. Regards, -- peter
Continue reading...
Continue reading...