On Wed, Feb 22, 2017 at 2:13 AM, Thanuja Jayasinghe <than...@wso2.com>
wrote:

> Hi Johann,
>
> On Tue, Feb 21, 2017 at 12:58 AM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi Isura,
>>
>> On Mon, Feb 20, 2017 at 5:23 PM, Isura Karunaratne <is...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> On Mon, Feb 20, 2017 at 2:20 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Hi Ayesha,
>>>>
>>>> On Mon, Feb 20, 2017 at 11:49 AM, Ayesha Dissanayaka <aye...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In Identity Management we have the concept of unique claims which can
>>>>> only have a unique value within a domain.
>>>>> With the value of a unique claim we can identify a unique user within
>>>>> a domain. While implementing identity management capabilities in IS-6.0
>>>>> User portal we came across below concerns.
>>>>>
>>>>>    - System can have one or more unique claims.
>>>>>
>>>>> Can't it be zero? W have a globally unique UUID. Must we always have a
>>>> unique claim also within a domain? Can't we say a combination of claims
>>>> make the user unique? If there isn't anything like that in the system then
>>>> the user can't perform recovery. Is that a acceptable? I don't think in amy
>>>> practical system we can't find a combination of claims that identify the
>>>> user uniquely in the domain.
>>>>
>>>
>>> If it is zero, we have to use unique UUID as the unique idefier for all
>>> the opeartions such as authentication, recovery. It is not practical to
>>> remember unique UUID, so an external applicatoin should have the mapping
>>> between unique UUID and username. Do we support zero unique claim scenario?
>>>
>>
>> What I meant by zero unique claims is, there is not one single unique
>> claim in the system. But there is a set of claims whose combination of
>> values will uniquely identify the user. This needs to be defined using
>> attribute profile.
>>
>
> Yes. For recovery scenarios, we can identify a user using a combination of
> non-unique claims. So having at least one unique claim is not a requirement
> for identity management features.
>
> Having at least one unique claim comes with authentication feature.
> Otherwise, there may be cases which we have to depend on the password to
> differentiate users. So we have atleast one unique claim by defult?
>

Even now in C4 we have customers who have duplicate usernames across their
user stores (across domains). Any reason why we need to change this design
and mandate one unique claim per user domain always?

And also 90% of the time users in enterprise login with a domain qualified
name. Some customers have customized the login page to take in the domain
as a separate input and username as separate input. Domain is not optional
for them. So under those circumstances I don't think introducing a new
constraint saying there MUST be at least one claim that uniquely identifies
the user across domains is necessary. We are limiting ourselves too much I
think.

May be others can weigh in.


>
>>
>>
>>>
>>> If we don't define a unique claim, how to identify the correct
>>> DomainUser object for authentication. Fllowing is the existing API for
>>> authentication and if there is no unique claim, we need to create a new API
>>> with unique userid.
>>>
>>>
>>>
>>>   AuthenticationContext authenticate(Claim claim, Callback[]
>>> credentials, String domainName)
>>>
>>>         throws AuthenticationFailure, IdentityStoreException;
>>>
>>>
>>>
>>>
>>>
>>>>>    - All the unique claims doesn't have to be required claims.
>>>>>
>>>>> Yes.
>>>>
>>>>>
>>>>>    -
>>>>>    - At least one unique claim has to be required claim.
>>>>>
>>>>> If we go with my previous explanation, if one claim isn't enough to
>>>> identify the user uniquely then there can be more claims that are required.
>>>>
>>>>>
>>>>>    -
>>>>>
>>>>> For authentication and recovery scenarios we need to have a unique
>>>>> identifier for users. Currently we use "username" claim. I assume we need
>>>>> to provide the flexibility to change this identifier claim.
>>>>>
>>>>>    1. Do we allow client applications to choose this identifier claim
>>>>>    from unique claims?
>>>>>       - Then the IS will have to accept any of the unique claims as
>>>>>       the user identifier in authentication and validate against it.
>>>>>
>>>>> No need to let client applications choose this. We are talking about
>>>> account recovery of an account centrally and solely managed by IS, and it
>>>> is the sole responsibility of IS to allow its to recover their accounts
>>>> securely and efficiently. Applications don't need to specify criteria for
>>>> this process and change security requirements for the process.
>>>>
>>> +1
>>>
>>>
>>>>
>>>>>    -
>>>>>    1. Otherwise should we keep it as a system wide configuration?
>>>>>
>>>>> Yes, it's a system (tenant) configuration.
>>>>
>>>>>
>>>>>    1. For the User Portal, we use 'username' claim as the user
>>>>>    identifier. I have noticed we have hard-coded this claim 
>>>>> '*http://wso2.org/claims/username
>>>>>    <http://wso2.org/claims/username>*'.
>>>>>    1. I think we need to get this value from a configuration.
>>>>>       2. Is it OK to keep this as a configuration within the User
>>>>>       Portal.
>>>>>       3. Otherwise where should we keep this?
>>>>>       4. Will this identifier be username, for User portal always?
>>>>>       Otherwise we need to have the flexibility of changing UI labels 
>>>>> according
>>>>>       to the identifier without much effort.
>>>>>
>>>>> Can't this be handled by attribute profile feature? Again the answer
>>>> depends on the answer for my previous question, about having a set of
>>>> claims that uniquely identify a user in a domain.
>>>>
>>>>>
>>>>>    1. Should we support authentication and recovery by multiple
>>>>>    identifiers ( ex: username or email or NIC, each representing an 
>>>>> individual
>>>>>    unique claim)
>>>>>
>>>>> Password based authentication - yes. Since we take in a password that
>>>> has very low probability of being the same of another user within the
>>>> domain for the same claim identifier, we can actually allow authentication
>>>> with any claim - doesn't necessarily have to be unique.
>>>>
>>>> However for recovery we must identify user uniquely and for that we
>>>> need to have a set of claims that identify the user uniquely within a
>>>> domain. Again can we use the attribute profile concept here?
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>>> Appreciate your input on this.
>>>>>
>>>>> Thanks!
>>>>> -Ayesha
>>>>>
>>>>> --
>>>>> *Ayesha Dissanayaka*
>>>>> Software Engineer,
>>>>> WSO2, Inc : http://wso2.com
>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg>
>>>>> 20, Palmgrove Avenue, Colombo 3
>>>>> E-Mail: aye...@wso2.com <ayshsa...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> *Johann Dilantha Nallathamby*
>>>> Technical Lead & Product Lead of WSO2 Identity Server
>>>> Governance Technologies Team
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - *+94777776950*
>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+94777776950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
> Thanks,
> Thanuja
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+94777776950*
Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to