Hi Dewni,
In SCIM, it allows to define email addresses as a primitive strings as
well. In the current architecture, we are using the
http://wso2.org/claims/emailaddress to store the emails as a comma
separated string. For example, the following request is a valid case in
SCIM.
curl -v -k --user admin:admin --data
'{"schemas":[],"name":{"familyName":"sathya","givenName":"sathya"},"userName":"sathya","password":"sathya","emails":["
[email protected]","[email protected]"]}' --header
"Content-Type:application/json" https://localhost:9443/scim2/Users
Proceeding forward, I think we may have to provide support to verify
multiple emails in the http://wso2.org/claims/emailaddress claim if exists,
or introduce a new claim e.g. http://wso2.org/claims/emails to store the
primitive values.
Thanks,
Sathya
On Wed, Jan 29, 2020 at 4:50 PM Dewni Weeraman <[email protected]> wrote:
> Hi All,
>
> The "emailaddress.verificationPending" (
> http://wso2.org/identity/claims/emailaddress.verificationPending) claim
> suggests a boolean value instead of the actual email value. Therefore we
> will modify the claim name as "emailaddress.pendingValue" (
> http://wso2.org/identity/claims/emailaddress.pendingValue) to avoid
> any confusion.
>
> As discussed previously, we will be providing the verification on update
> functionality for the "emailaddress" (http://wso2.org/claims/emailaddress)
> claim for now. However, we have planned to extend this functionality for
> other claims such as "emails.work" (http://wso2.org/claims/emails.work)
> and "emails.home" (http://wso2.org/claims/emails.home) in the future.
> Therefore it is important to have a proper format when representing these
> verification pending claims in the SCIM response. The ideal solution is to
> have a "pendingValue" for each of these claims.
>
> Please find the sample request and response.
>
> Request:
>
> *curl -v -k --user admin:admin -X PATCH -d
> '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[
> {"op":"replace","value":{"emails":[{"primary":true,"value":"[email protected]
> <[email protected]>"}]}}]}' --header "Content-Type:application/json"
> https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
> <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>*
>
>
> Response:
>
> *{"emails":["[email protected]
> <[email protected]>"],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
> <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"Internal/everyone"}],"name":{"givenName":"dewni","familyName":"jackson"},"id":"705cc75d-2640-4c3d-9848-e055a9eb6109","userName":"dewnitest","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"emails":[{"pendingValue":"[email protected]
> <[email protected]>"}]}}*
>
> When we extend the feature to support verification of other claims such as
> "emails.work" in the future, the SCIM 2.0 response should be as below.
>
> Response:
>
> *{"emails":["[email protected] <[email protected]>",
> **{"type":"work","value":"[email protected]
> <[email protected]>"},{"type":"home","value":"[email protected]
> <[email protected]>"}**],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
> <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"Internal/everyone"}],"name":{"givenName":"dewni","familyName":"jackson"},"id":"705cc75d-2640-4c3d-9848-e055a9eb6109","userName":"dewnitest","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"emails":[{"pendingValue":"[email protected]
> <[email protected]>"},{"type":"work","**pendingValue**":"[email protected]
> <[email protected]>"},{"type":"home","**pendingValue**":"[email protected]
> <[email protected]>"}]}}*
>
>
>
> Kind regards,
> Dewni
>
> --
> Dewni Weeraman | Software Engineer | WSO2 Inc.
> (m) +94 077 2979049 | (e) [email protected] <[email protected]>
>
> <http://wso2.com/signature>
>
>
> On Tue, Jan 21, 2020 at 5:50 PM Godwin Shrimal <[email protected]> wrote:
>
>> +1 to have a consistency of defining claims. We have a claim [1] which
>> saying the word "verify email" and need to extra care on the claim name and
>> it's good claim URI self explain the usage of it. Any particular reason to
>> use userstore claim (
>> http://wso2.org/claims/emailaddress.verificationPending) here without
>> using identity claim? Introducing map attributes in the existing LDAP,
>> AD is not something easy.
>>
>> [1] http://wso2.org/claims/identity/verifyEmail
>>
>> Thanks
>> Godwin
>>
>> On Tue, Jan 21, 2020 at 7:28 AM Malithi Edirisinghe <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 20, 2020 at 5:09 PM Ruwan Abeykoon <[email protected]> wrote:
>>>
>>>> Hi Dewni/Malithi,
>>>>
>>>> Can we use "*Primary*Email.verificationPending" instead of
>>>> verificationPending*Primary*Email?
>>>> In this way we can design a regex for any future pending verifications,
>>>> like "PrimaryPhone.verificationPending"
>>>>
>>>
>>> +1.
>>> @Dewni Weeraman <[email protected]> , as this binds to the "emailaddress" (
>>> http://wso2.org/claims/emailaddress) claim right now, I think we can
>>> have it as "emailaddress.verificationPending" (
>>> http://wso2.org/claims/emailaddress.verificationPending).
>>>
>>> So that it properly reflects for which claim verification is pending.
>>>
>>>
>>>> Cheers,
>>>> Ruwan A
>>>>
>>>> On Mon, Jan 20, 2020 at 6:20 AM Dewni Weeraman <[email protected]> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We will be providing the feature for $subject only in instances where
>>>>> the user's primary email address is to be updated. When a SCIM update
>>>>> request for the primary email address is performed, the email address to
>>>>> which the verification email is sent is represented via the
>>>>> "verificationPendingPrimaryEmail" attribute in the SCIM response body.
>>>>> The mutability of "verificationPendingPrimaryEmail" attribute will be set
>>>>> to *readOnly *so as to prevent direct insertion or modification of
>>>>> this attribute via a SCIM request. Please note that initially this new
>>>>> attribute was planned to be named as "verificationPendingEmail", however
>>>>> since the above feature is only applicable for the primary email address,
>>>>> we have changed the wording to "verificationPending*Primary*Email" to
>>>>> avoid any confusion.
>>>>>
>>>>> In a scenario where the update request contains claims in addition to
>>>>> the email address, these other claims will be updated. The HTTP response
>>>>> status code will be *200 - OK. *As discussed previously in this mail
>>>>> thread the email claim will not be updated. The new email address is
>>>>> stored against "verificationPendingPrimaryEmail" claim until the
>>>>> verification process has been completed successfully.
>>>>>
>>>>> Formerly it was decided that the presence of the "verifyEmail"
>>>>> attribute in the SCIM request is mandatory to trigger the verification. We
>>>>> have identified that then we will have the complexity of handling update
>>>>> requests to SCIM /Me endpoint and /Users endpoint separately. The reason
>>>>> for this is the user can update the email address directly using the /Me
>>>>> endpoint without triggering an email verification if the request doesn't
>>>>> contain "verifyEmail" attribute despite the feature being enabled via the
>>>>> server configuration or not. To avoid this malicious behavior we have
>>>>> decided that enabling this feature will solely depend on the server
>>>>> configuration and we will not be checking on the availability of
>>>>> "verifyEmail" attribute in the SCIM request.
>>>>>
>>>>> Thanks,
>>>>> Dewni
>>>>>
>>>>> On Mon, Jan 20, 2020 at 7:29 AM Malithi Edirisinghe <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 18, 2020 at 6:18 PM Johann Nallathamby <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Malithi, Hi Ajanthan,
>>>>>>>
>>>>>>> OK. So if we think like that, how do you propose we do 2FA for
>>>>>>> security question update? Are you implying that we initiate a SSO flow
>>>>>>> with
>>>>>>> higher requested assurance level, so that in IS a step-up
>>>>>>> authentication is
>>>>>>> performed and returned back to the service provider, to update his/her
>>>>>>> security questions?
>>>>>>>
>>>>>>
>>>>>> Yes. And we can do this with conditional auth scripts.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> If this is possible with IS then +1 for that. But also I would like
>>>>>>> to have in the roadmap to do this purely through Rest APIs without ever
>>>>>>> leaving the service provider.
>>>>>>>
>>>>>>
>>>>>> I think it's subjective. Maybe if it's some email or mobile based
>>>>>> confirmation it would be fine. But, for advanced options service provider
>>>>>> will have to manage user interactions if so. What would be the tendency
>>>>>> to
>>>>>> implement such in SP level.
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Johann.
>>>>>>>
>>>>>>> On Thu, Jan 16, 2020 at 7:28 AM Malithi Edirisinghe <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Johann,
>>>>>>>>
>>>>>>>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Johann,
>>>>>>>>>
>>>>>>>>> I think here we are talking about two different things. Feel free
>>>>>>>>> to correct me if I am wrong.
>>>>>>>>>
>>>>>>>>> In the first case, we are trying to assert the value of the claims
>>>>>>>>> provided by the user. In the case of phone number and email claims
>>>>>>>>> sending
>>>>>>>>> verification code does make sense but to assert the first name or
>>>>>>>>> last name
>>>>>>>>> sending verification code to email or phone doesn't give enough
>>>>>>>>> assurance(usually photo ID proof is needed to verify names).
>>>>>>>>>
>>>>>>>>> What you are talking about is getting enough assurance level for
>>>>>>>>> the authenticated user by prompting 2FA to be able to update security
>>>>>>>>> questions. This should be handled by auth system not the claim
>>>>>>>>> verification
>>>>>>>>> system.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm under the same understanding with Ajanthan.
>>>>>>>> It should be a 2FA flow.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ajanthan.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Malithi
>>>>>>>> --
>>>>>>>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
>>>>>>>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) [email protected]
>>>>>>>> GET INTEGRATION AGILE
>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions
>>>>>>> Architect | WSO2 Inc.
>>>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected]
>>>>>>> [image: Signature.jpg]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
>>>>>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) [email protected]
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dewni Weeraman | Software Engineer | WSO2 Inc.
>>>>> (m) +94 077 2979049 | (e) [email protected] <[email protected]>
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
>>>> (w) +947435800 | Email: [email protected]
>>>>
>>>>
>>> Thanks,
>>> Malithi.
>>> --
>>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
>>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) [email protected]
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Godwin Amila Shrimal | Technical Lead | WSO2 Inc.
>> (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) [email protected]
>> <http://wso2.com/signature>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Dewni Weeraman | Software Engineer | WSO2 Inc.
> (m) +94 077 2979049 | (e) [email protected] <[email protected]>
>
> <http://wso2.com/signature>
>
>
>
--
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421
<+94%2071%20411%205032>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
