Hi Damith,
You can find corresponding source in [1]. You can see that the claimDO is
stored with respective to the userStoreManager.
public void store(UserIdentityClaimsDO userIdentityDTO,
UserStoreManager userStoreManager) throws IdentityException {
UserIdentityClaimsDO newIdentityClaimDO = new
UserIdentityClaimsDO(userIdentityDTO.getUserName(),
userIdentityDTO.getUserDataMap());
super.store(newIdentityClaimDO, userStoreManager);
If you are using the IS 5.1.0 source, find the corresponding one in github.
[1]
https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/identity/org.wso2.carbon.identity.mgt/4.2.3/src/main/java/org/wso2/carbon/identity/mgt/store/UserStoreBasedIdentityDataStore.java
On Wed, Apr 29, 2015 at 11:12 AM, Tharindu Edirisinghe <[email protected]>
wrote:
> Hi Damith,
>
> You can refer [1] for enabling the Account Lock feature in Identity
> Server. You have to add the following claims in the wso2.org claim
> dialect. (accountLocked claim is already there by default. You need to add
> the other two)
>
>
>
> - http://wso2.org/claims/identity/accountLocked
>
> mapped attribute - initials
>
>
> - http://wso2.org/claims/identity/unlockTime
>
> mapped attribute - unlockTime
>
>
> - http://wso2.org/claims/identity/failedLoginAttempts
>
> mapped attribute - failedLoginAttempts
>
> The values for above are actually persisted. If the user is in LDAP and
> when the feature is activated you'll see corresponding values in
> 'initials', 'unlockTime' and 'failedLoginAttempts' attributes if you browse
> the LDAP using ApacheDS.
>
> If you are using a JDBC (database) userstore, you can see those values in
> the UM_USER_ATTRIBUTE table.
>
> Note that for accountLocked claim, we give the attribute name as initials
> because in WSO2 LDAP schema, there is no attribute defined with the name
> accountLocked. Therefore we use an existing attribute such as initials
> which will contain true/false to show that the user account is locked or
> not.
>
> If you need more help, let me know.
>
> [1] https://docs.wso2.com/pages/viewpage.action?pageId=34612027
>
> Regards,
> TharinduE
>
> On Wed, Apr 29, 2015 at 10:54 AM, Damith Senanayake <[email protected]>
> wrote:
>
>> Hi,
>>
>> I have been trying to fix a bug [
>> https://wso2.org/jira/browse/IDENTITY-3235
>> <https://www.google.com/url?q=https%3A%2F%2Fwso2.org%2Fjira%2Fbrowse%2FIDENTITY-3235&sa=D&sntz=1&usg=AFQjCNErzS46IPaEGxwAFhOKGDQUPlmZdA>
>> ] and I have noticed that when we try to login from the Primary domain, the
>> UserStoreManager( a ReadWriteLDAPUserStoreManager ) contains the
>> 'userCache' member which has stored the logged in users from the primary
>> domain. However, if we have a secondary user store (A jdbc store, say) the
>> same cannot be found.
>>
>> I am having trouble understanding how the locked users are stored in this
>> information flow. For instance, if a user from the primary domain gets
>> locked with max number of failed attempts, that information is stored in
>> the userClaimsDo instance pertaining to that user, in the
>> userIdentityDataMap. And then this user is put into a cache. What I need to
>> know is, is it intended to be non-persistent (the locked details go away
>> when we restart the server) or is there a persistent storage mechanism
>> involved.
>>
>> Secondly, I am trying to figure out where the userStore domain
>> information is stored in one these user instances at the back end. Any
>> idea where to start looking for that?
>>
>>
>> Thanks.
>> --
>> *-Damith Senanayake-*
>> +94712205272
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> Tharindu Edirisinghe
> Software Engineer | WSO2 Inc
> Identity Server Team
> mobile : +94 775 181586
>
--
Tharindu Edirisinghe
Software Engineer | WSO2 Inc
Identity Server Team
mobile : +94 775 181586
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
