Hi Ryan, I do this myself in my applications as well with multiple realms. But I don't have the Ki components do this directly. Instead, I have a that performs all user-specific functionality.
What you're talking about is really business logic unrelated to Ki, so it belongs in a business-tier component. Here's how I do this kind of stuff (a little simplified though for this discussion): I have a UserService interface with a DefaultUserService implementation. There will be a UserService.login(String username, String password); interface method. The implementation can use the Ki Subject to perform the logic. If the authentication succeeds, I check (via a UserDAO) if there is a corresponding record in the RDBMS for that login. If not, I create one at that time, making the appropriate association with the LDAP credentials. Then the method returns quietly if there are no problems, otherwise throws application-specific exceptions (not Ki Exceptions) if something goes wrong to let the GUI know what went wrong. I hope that helps! Cheers, Les On Fri, Mar 27, 2009 at 8:53 PM, Ryan McKinley <[email protected]> wrote: > Hello- > > I am building an application that needs a user model, but the > authentication may be elsewhere (LDAP whatever) -- is there any advice on > the best way to design this? > > Say I have a user class User, and store info like name, email, list of > "favorites", etc, etc. Consider the case where the user authenticates > successfully on an LDAP server, but that user does not exist in my local > database: are there any suggested models for where to trigger creating a > new User class? Perhaps I need to extend a SecurityManager and then make > Users on #createSubject() -- perhaps a wrapper Realm that creates a user on > successful login. Are there an general practices people use? > > Another question is if the User should be attached to the Subject somehow. > Alternatively, Subject#getPrincipal() could be used to grab the User class > whenever it is needed. > > Any advice would be great. I'll do my best to distill any best practices > in the wicketstuff example apps. > > Thanks again > ryan >
