-
1. Re: Extending Seam Security to Include Domain
serkan Mar 30, 2012 5:56 AM (in response to zenig)As always read the manual before looking in the source code
What you describe is not necessary. It's very easy, just extend the Identity with your extra properties (e.g. domain) and that will be enough.
See http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/security.html#d0e13857
Then inject your custom identity into your authentication class (instead of the default one) and handle the logic.
-
2. Re: Extending Seam Security to Include Domain
zenig Apr 1, 2012 10:31 AM (in response to serkan)I was extending the Credentials per Seam in Action (page 438). I did look at the manual about extending the Identity. I could understanding doing this so you can inject the Credentials into the authenticate method. Then you would just provide the query to validate the password.
But, I am using IdentityMangager as well as JPAIdentityStore. This is where my issue lies. The IdentityManager does support "createUser(String domain, String username, String password)". So if I extend IdentityManager, then going further I would have to extend JPAIdentityStore and the number of classes I have to extend continues to increase from there.
I hope that makes more sense. I have elected to just put the "domain\username" as the username field in Credentials. It isn't elegent but all I had to do was extend Credentials. It just puts "domain\username" in the database which I wanted as separate columns. But, it shall do!
If anybody knows how to make this more elegent, then let me know. When I eventually move to Delta Spike or the next iteration of Seam, I'll see if PickLink is more flexible for this purpose.
-
3. Re: Extending Seam Security to Include Domain
serkan Apr 1, 2012 9:40 AM (in response to zenig)Ok I understand your problem now.
If you're using the IdentityManager then it's actually more easy, you don't have to extend Credentials nor Identity.
Just put the domain in your own User entity class and make a listener to @Observer(JpaIdentityStore.EVENT_PRE_PERSIST_USER) and
set the domain into user here.
Here is my own code example:
/**
* Called when <tt>identityManager.createUser()</tt> has been executed.
*
* @param account the account that is going to be created.
*/
@Observer(JpaIdentityStore.EVENT_PRE_PERSIST_USER)
public void register(Account account) {
if (newUser != null)
account.setUser(newUser);
activationCode = UUID.randomUUID().toString().replaceAll("-", "").toUpperCase();
account.setActivationCode(activationCode);
account.setCreated(new Date());
account.setEnabled(false);
account.setScreenname(username);
account.setRole(role);
}
Hope this helps you.
-
4. Re: Extending Seam Security to Include Domain
zenig Apr 1, 2012 10:39 AM (in response to serkan)I looked into that too!
Here are two scenarios:
Scenario 1:
Domain: domain1
Username: jsmith
Password: 1234
Scenario 2:
Domain: domain2
Username: jsmith
Password: 1234
When I try to use createUser(String username, String password) in IdentityManager, the first user is created sucessfully. Then when I try to create the second user, it says it already exists! I want the combination of "domain" and "username" to represent a unique user, not just the default "username". This will allow the same username within separate domains to be handled.
-
5. Re: Extending Seam Security to Include Domain
serkan Apr 1, 2012 12:03 PM (in response to zenig)Check this out:
https://community.jboss.org/thread/189160
You probably have to override IdentityManager's auehnticate functioanlity and if things become complicated I would switch back to the default simple authenication without making use of the IdentityManager. That's more flexible and you can define your own authentication method.
-
6. Re: Extending Seam Security to Include Domain
zenig Apr 1, 2012 8:55 PM (in response to serkan)I saw that link too during my search. Close! For what he wants to do, he seems to be focused just on the JPA lookup method and nothing else.
I think my best bet is to venture off on my own or continue to use my hack above hoping the next iteration of the security framework considers this scenario.
Thanks!