Re: [Architecture] [IAM] Supporting email verification when user’s email address is updated

[Godwin Shrimal]

+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 
wrote:

>
>
> On Mon, Jan 20, 2020 at 5:09 PM Ruwan Abeykoon  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  , 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  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 
>>> wrote:
>>>


 On Sat, Jan 18, 2020 at 6:18 PM Johann Nallathamby 
 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 
> wrote:
>
>> Hi Johann,
>>
>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran <
>> ajant...@wso2.com> 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 

Re: [Architecture] IAM Controller(IAM-CTL)- Command Line Extension for WSO2 Identity Server

[Godwin Shrimal]

Hi Piyumi,

Interesting to see this and please share the low level design details when
those are ready. I hope we can(will) implement other areas such as user
store, identity provider etc with this CLI and please keep the design/user
experience flexible to those without stick only into service providers.

Thanks
Godwin

On Mon, Jan 20, 2020 at 9:26 AM Piyumi Madhubhashini 
wrote:

> Hi all,
>
> We have started to implement the command line extension for Identity
> server called IAM controller(IAM-CTL). This will enhance the developer’s
> experiences of IAM artifact which is a service provider. It will help to
> create service providers and view the list of  service providers easily
> through the terminal. Initially, this command line extension will support
> creating basic and oauth applications only.
>
> The command line extension will be implemented using Go language, cobra
> and survey packages. The main reason to select the Go language is Go’s
> program compiled as a static executable binary file. So it can be run
> directly and there is no need to install external dependencies. Hence it is
> unnecessary to worry about the various packages and library dependencies
> required by the command line extension. So this makes deployment very
> convenient.
>
> The command line extension will use Application Management REST API as the
> endpoint of Identity Server. To authenticate, password grant type with the
> Application Management REST API will be used.
>
> Here I have attached the high-level architecture as well.
>
>
> Thanks and regards,
>
> --
> *Piyumi Madhubhashini *| Intern- Engineering team | WSO2
>
> (m) +94778345567 | (e)  piyu...@wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 
Godwin Amila Shrimal | Technical Lead | WSO2 Inc.
(m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Supporting email verification when user’s email address is updated

[Godwin Shrimal]

Hi Malithi,

Thanks for the response. Please see my comment inline below.


On Thu, Jan 16, 2020 at 2:13 AM Malithi Edirisinghe 
wrote:

> Hi Godwin,
>
> On Wed, Jan 15, 2020 at 3:35 PM Godwin Shrimal  wrote:
>
>> Hi All,
>>
>> Sorry for the late to reply to this email. I have following concerns on
>> this feature.
>>
>> 1. Generalizing the feature: I think Johann and Isura also have pointed
>> the same. It looks like this feature is pretty much coupled to the email
>> claim, this same feature can be applied to phone number, IMID etc. So any
>> specific reason why we are not generalizing this and in future we can apply
>> to different scenarios ?
>>
>
> Please refer my reply to Isura's point above.
> We have been having these discussions some time for verifiable claims [1]
> and notifiable claims [2].
> We don't have these concepts properly in place still. Right now we have
> only email claim. So the focus here, is to fix the feature gap we have
> right now in initiating a verification flow on email update.
> As we proceed we can look into bringing the core feature supporting
> verifiable claims or notifiable claims end to end.
>
>
>>
>> 2. Complexity of applying: I feel following note gives some complexities
>> when comes to the real world scenarios. There may be existing system with
>> existing user base and we need to enable this feature. In such cases, we
>> need to think about user data update, migration etc. So there should not be
>> much overhead on using this feature. Do we have any option for that ?
>>
>> "An admin needs to enable “verifyEmail” claim during user creation to
>> support this feature"
>>
>
> A verification flow can be triggered in request path with 'verifyEmail'
> temporary claim. So that it can be triggered for an existing user base as
> well.
> Yet, our main assumption is when plugging an existing user base, or
> interacting with some other IdP, the claims they bring in are pre-verified.
> Hope I answered your question here.
>
[Godwin: According to the above note ("An admin needs to enable
“verifyEmail” claim during user creation to support this feature"), I
thought we could have enabled Email verification while creating existing
users in the userstore. Is my understanding correct ? If so, how can we
enable this feature in a system we haven't enabled email verification ]

Thanks
Godwin

>
>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Jan 15, 2020 at 2:59 AM Dewni Weeraman  wrote:
>>
>>> Hi All,
>>>
>>> Currently, I'm in the final stages of implementing the feature for email
>>> verification when user’s email address is updated. The expected
>>> functionality is achieved by persisting the newly updated email in a newly
>>> configured identity claim: "verificationPendingEmail" claim until the user
>>> verifies the updated email. An email notification will be triggered to the
>>> newly updated email address. Upon successful email account verification,
>>> "emailaddress" claim will be updated with the newly verified email address.
>>>
>>> This feature is invoked via a SCIM 2.0 PATCH request to update the email
>>> address. Please find the sample request and response.
>>>
>>> Request:
>>>
>>> *curl -v -k --user testuser:password -X PATCH -d
>>> '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"add","value":{"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"verifyEmail":"true"}}},{"op":"replace","value":{"emails":[{"primary":true,"value":"jack...@abc.com
>>> "}]}}]}' --header "Content-Type:application/json"
>>> https://localhost:9443/scim2/Me <https://localhost:9443/scim2/Me>*
>>>
>>>
>>> Response:
>>>
>>> *{"emails":["kim.jack...@gmail.com
>>> "],"meta":{"created":"2020-01-14T07:41:43.662120Z","location":"https://localhost:9443/scim2/Users/0a472190-c862-4f08-aa97-147cff1a714e
>>> <https://localhost:9443/scim2/Users/0a472190-c862-4f08-aa97-147cff1a714e>","lastModified":"2020-01-14T08:34:32.596354Z","resourceType":"User"},"schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":&quo

Re: [Architecture] [IAM] Supporting email verification when user’s email address is updated

[Godwin Shrimal]

Hi All,

Sorry for the late to reply to this email. I have following concerns on
this feature.

1. Generalizing the feature: I think Johann and Isura also have pointed the
same. It looks like this feature is pretty much coupled to the email claim,
this same feature can be applied to phone number, IMID etc. So any specific
reason why we are not generalizing this and in future we can apply to
different scenarios ?

2. Complexity of applying: I feel following note gives some complexities
when comes to the real world scenarios. There may be existing system with
existing user base and we need to enable this feature. In such cases, we
need to think about user data update, migration etc. So there should not be
much overhead on using this feature. Do we have any option for that ?

"An admin needs to enable “verifyEmail” claim during user creation to
support this feature"

Thanks
Godwin

On Wed, Jan 15, 2020 at 2:59 AM Dewni Weeraman  wrote:

> Hi All,
>
> Currently, I'm in the final stages of implementing the feature for email
> verification when user’s email address is updated. The expected
> functionality is achieved by persisting the newly updated email in a newly
> configured identity claim: "verificationPendingEmail" claim until the user
> verifies the updated email. An email notification will be triggered to the
> newly updated email address. Upon successful email account verification,
> "emailaddress" claim will be updated with the newly verified email address.
>
> This feature is invoked via a SCIM 2.0 PATCH request to update the email
> address. Please find the sample request and response.
>
> Request:
>
> *curl -v -k --user testuser:password -X PATCH -d
> '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"add","value":{"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"verifyEmail":"true"}}},{"op":"replace","value":{"emails":[{"primary":true,"value":"jack...@abc.com
> "}]}}]}' --header "Content-Type:application/json"
> https://localhost:9443/scim2/Me *
>
>
> Response:
>
> *{"emails":["kim.jack...@gmail.com
> "],"meta":{"created":"2020-01-14T07:41:43.662120Z","location":"https://localhost:9443/scim2/Users/0a472190-c862-4f08-aa97-147cff1a714e
> ","lastModified":"2020-01-14T08:34:32.596354Z","resourceType":"User"},"schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"testrole,Internal/everyone"}],"name":{"givenName":"kim","familyName":"jackson"},"groups":[{"display":"testrole","value":"fea41f11-0160-4fc2-9af5-a9158ed1cc8f","$ref":"https://localhost:9443/scim2/Groups/fea41f11-0160-4fc2-9af5-a9158ed1cc8f
> "}],"id":"0a472190-c862-4f08-aa97-147cff1a714e","userName":"testuser","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"verificationPendingEmail":"jack...@abc.com
> "}}*
>
>
> As in the above response, the already existing email address will be
> displayed with the "emails" attribute while the newly updated email is
> displayed with "verificationPendingEmail" attribute.
>
> As defined in the SCIM specification [1], on successful completion of a
> PATCH request, the server returns either *200 - OK* or *204 - No Content*.
> In this feature implementation, the HTTP response status code needs to be *202
> -Accepted* to indicate that the request has been accepted but the
> processing has not been completed since the updated email is not verified.
> Therefore we are currently having concerns regarding the recommended HTTP
> status code to be returned with the SCIM response.
>
> Your input regarding the HTTP status code on this matter is highly
> appreciated. Also, I have sent an email to the SCIM public mailing list
> regarding our concern on the recommended approach to be followed to achieve
> this use case which requires a verifiable claim to be updated.
>
> [1] https://tools.ietf.org/html/rfc7644#section-3.5.2
>
> Kind regards,
> Dewni Weeraman
>
> On Wed, Jan 8, 2020 at 4:50 AM Ajanthan Balachandran 
> 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.
>>
>> Thanks,
>> Ajanthan.
>>
>> 

[Architecture] [IAM] Remember me device management

[Godwin Shrimal]

Hi All,


Requirement

   1.

   Maintain list of Remembered devices and show it in the user’s profile
   2.

   There should be a consent page in the authentication flow to get the
   user’s consent and description/name for the device (Human readable) and we
   need to persist. Should be able to skip the consent page
   3.

   There is an option to “Forget device” where user can remove Remembered
   devices from user profile.


Please see the proposed solutions for this requirement.

Solution1

   1.

   Keep a separate table to maintain device information
   2.

   Expose device CRUD operations as rest services
   3.

   Store some signed information in the cookie with some unique identifier
   4.

   When user login need to extract the cookie and do the validation with
   what we have persisted in the table (We need to decide how enforcement
   happens. Ex. using an authenticator or some other way)


Solution2

   1.

   Maintain device information as a claim of a user
   2.

   Since user can have multiple devices, claim will be a json content with
   multiple devices information
   3.

   Use SCIM API to get/update claim of the user


Solution3

Use current consent management implementation to maintain remembered
devices. Here we either have to maintain device ID as PII or as a property.
If we are maintaining as a PII, we need to add device ID as a PII category
and then its creating PII category per device.

Note: Maintaining device as PII category having scalability issues and
maintaining device ID in the property also not a clean solution for this.

>From above solutions, I would like to go ahead with the claim based
solution (Solution2) since it’s more suitable with the current capabilities
we having in consent mgt.

Appreciate your thoughts.

Thanks

Godwin
-- 
Godwin Amila Shrimal | Technical Lead | WSO2 Inc.
(m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

Thanks for the response Vihanga, So according to your response.

Encryption Algorithm = Asymmetric Key Encryption Algorithm
Encryption Method = Symmetric Key Encryption Algorithm

Yeah, I think its bit confusing. we may use better names than lib. nothing
comes to my mind now :)

Thanks
Godwin

On Thu, Mar 8, 2018 at 10:00 AM, Vihanga Liyanage <viha...@wso2.com> wrote:

> The encryption algorithm is the asymmetric key encryption algorithm that
> is used to encrypt the CEK with the recipient's public key. I've updated
> these in the public docs [1], [2]. I know these two names are confusing a
> bit. I just followed the lib for the time being.
>
> I'd be happy to talk about a suitable name pair. :)
>
> [1] - https://docs.wso2.com/display/IS550/Decrypting+OpenID+Connec
> t+Encrypted+ID+Tokens
> [2] - https://docs.wso2.com/display/IS550/Testing+OIDC+Encrypted+
> ID+Token+with+IS+5.5.0
>
> On Thu, Mar 8, 2018 at 9:53 AM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Well, if Encryption Method mentioned is referring to "symmetric key
>> encryption algorithm", What is "Encryption Algorithm" on the screen?
>>
>>
>> Thanks
>> Godwin
>>
>> On Thu, Mar 8, 2018 at 9:47 AM, Godwin Shrimal <god...@wso2.com> wrote:
>>
>>> Can you send me the list of values in that dropdown? Cipher Block
>>> Chaining is how we are chaining encrypted values since encryption happens
>>> as blocks (8 bit, 6 bit etc.) You can read about it here [1].
>>>
>>> [1] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Wed, Mar 7, 2018 at 10:57 PM, Vihanga Liyanage <viha...@wso2.com>
>>> wrote:
>>>
>>>> The Encryption Method mentioned here is the symmetric key encryption
>>>> algorithm that is used to encrypt the JWT claims set. We used the Nimbus
>>>> [1] <https://connect2id.com/products/nimbus-jose-jwt> library for the
>>>> implementation and within that, they have used the name "Encryption Method"
>>>> to identify this algorithm. They have a class defined as
>>>> com.nimbusds.jose.EncryptionMethod which wraps all supported symmetric
>>>> key encryption algorithms.
>>>> I took the name from there. I'm not sure what you mean by "cipher
>>>> chaining mode". Is this mentioned in the JWE RFC?
>>>>
>>>> [1] - https://connect2id.com/products/nimbus-jose-jwt
>>>>
>>>> On Wed, Mar 7, 2018 at 10:00 PM, Godwin Shrimal <god...@wso2.com>
>>>> wrote:
>>>>
>>>>> should be corrected as "Chaining Mode".
>>>>>
>>>>>
>>>>> Thanks
>>>>> Godwin
>>>>>
>>>>> On Wed, Mar 7, 2018 at 5:26 PM, Godwin Shrimal <god...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> "Encryption Method" is the correct term/word here? AFAIK It's cipher
>>>>>> chaining mode. I know it's a technical word, but still, I feel like we 
>>>>>> have
>>>>>> to use correct naming. Something  like "Chaning Mode".
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Godwin
>>>>>>
>>>>>> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage <viha...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> [Update]
>>>>>>> I have completed the second phase of the project, providing service
>>>>>>> provider level configurations in admin dashboard to configure encryption
>>>>>>> algorithm and encryption method. With this update, once you enable
>>>>>>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>>>>>>> will appear with supported encryption algorithms and supported 
>>>>>>> encryption
>>>>>>> methods. These supported algorithms are pulled from the identity.xml 
>>>>>>> file.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Respective git issue and pull requests are as follows.
>>>>>>>
>>>>>>>- https://github.com/wso2/product-is/issues/2387
>>>>>>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>>>>>>- https://github.com/wso2-

Re: [Architecture] [Dev] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

Can you send me the list of values in that dropdown? Cipher Block Chaining
is how we are chaining encrypted values since encryption happens as blocks
(8 bit, 6 bit etc.) You can read about it here [1].

[1] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Thanks
Godwin

On Wed, Mar 7, 2018 at 10:57 PM, Vihanga Liyanage <viha...@wso2.com> wrote:

> The Encryption Method mentioned here is the symmetric key encryption
> algorithm that is used to encrypt the JWT claims set. We used the Nimbus
> [1] <https://connect2id.com/products/nimbus-jose-jwt> library for the
> implementation and within that, they have used the name "Encryption Method"
> to identify this algorithm. They have a class defined as
> com.nimbusds.jose.EncryptionMethod which wraps all supported symmetric
> key encryption algorithms.
> I took the name from there. I'm not sure what you mean by "cipher chaining
> mode". Is this mentioned in the JWE RFC?
>
> [1] - https://connect2id.com/products/nimbus-jose-jwt
>
> On Wed, Mar 7, 2018 at 10:00 PM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> should be corrected as "Chaining Mode".
>>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Mar 7, 2018 at 5:26 PM, Godwin Shrimal <god...@wso2.com> wrote:
>>
>>> "Encryption Method" is the correct term/word here? AFAIK It's cipher
>>> chaining mode. I know it's a technical word, but still, I feel like we have
>>> to use correct naming. Something  like "Chaning Mode".
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage <viha...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> [Update]
>>>> I have completed the second phase of the project, providing service
>>>> provider level configurations in admin dashboard to configure encryption
>>>> algorithm and encryption method. With this update, once you enable
>>>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>>>> will appear with supported encryption algorithms and supported encryption
>>>> methods. These supported algorithms are pulled from the identity.xml file.
>>>>
>>>>
>>>>
>>>> Respective git issue and pull requests are as follows.
>>>>
>>>>- https://github.com/wso2/product-is/issues/2387
>>>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>>th/pull/832
>>>>
>>>> I have also updated the docs as well.
>>>>
>>>> Thanks,
>>>> Vihanga.
>>>>
>>>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage <viha...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> [Update]
>>>>> I was able to complete the initial development of the proposed
>>>>> project, encrypted id token support in OIDC flow. Following are the links
>>>>> related to the development.
>>>>>
>>>>>- An issue was created in product-is repository to track the
>>>>>development.
>>>>>   - https://github.com/wso2/product-is/issues/2336
>>>>>- Pull request is made to identity-inbound-auth-oauth repository
>>>>>with required updates.
>>>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>>>   th/pull/798
>>>>>- Pull request is made to product-is repository with updated
>>>>>playground application to test the feature
>>>>>- https://github.com/wso2/product-is/pull/2313
>>>>>- Code review was held to review the code written in both PRs.
>>>>>
>>>>> All PRs are merged by now.
>>>>> Currently, I'm working on integration test to test the newly added
>>>>> feature.
>>>>>
>>>>> Thanks,
>>>>> Vihanga
>>>>>
>>>>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage <viha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Yes, Farasath. As for the offline discussions with Drashana, I came
>>>>>> to the same conclusion and exploring the SAML sample app right now.
>>>>>>
>>>>>> Although I'm not sure about signing JWE. I couldn't find anything
>>>>>> specific a

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

should be corrected as "Chaining Mode".


Thanks
Godwin

On Wed, Mar 7, 2018 at 5:26 PM, Godwin Shrimal <god...@wso2.com> wrote:

> "Encryption Method" is the correct term/word here? AFAIK It's cipher
> chaining mode. I know it's a technical word, but still, I feel like we have
> to use correct naming. Something  like "Chaning Mode".
>
>
> Thanks
> Godwin
>
> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage <viha...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> [Update]
>> I have completed the second phase of the project, providing service
>> provider level configurations in admin dashboard to configure encryption
>> algorithm and encryption method. With this update, once you enable
>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>> will appear with supported encryption algorithms and supported encryption
>> methods. These supported algorithms are pulled from the identity.xml file.
>>
>>
>>
>> Respective git issue and pull requests are as follows.
>>
>>- https://github.com/wso2/product-is/issues/2387
>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>- https://github.com/wso2-extensions/identity-inbound-auth-
>>oauth/pull/832
>>
>> I have also updated the docs as well.
>>
>> Thanks,
>> Vihanga.
>>
>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage <viha...@wso2.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> [Update]
>>> I was able to complete the initial development of the proposed project,
>>> encrypted id token support in OIDC flow. Following are the links related to
>>> the development.
>>>
>>>- An issue was created in product-is repository to track the
>>>development.
>>>   - https://github.com/wso2/product-is/issues/2336
>>>- Pull request is made to identity-inbound-auth-oauth repository
>>>with required updates.
>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>   th/pull/798
>>>- Pull request is made to product-is repository with updated
>>>playground application to test the feature
>>>- https://github.com/wso2/product-is/pull/2313
>>>- Code review was held to review the code written in both PRs.
>>>
>>> All PRs are merged by now.
>>> Currently, I'm working on integration test to test the newly added
>>> feature.
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage <viha...@wso2.com>
>>> wrote:
>>>
>>>> Yes, Farasath. As for the offline discussions with Drashana, I came to
>>>> the same conclusion and exploring the SAML sample app right now.
>>>>
>>>> Although I'm not sure about signing JWE. I couldn't find anything
>>>> specific about that in the RFC. Also, the API in Nimbus only expects the
>>>> claims set and the public key of the client to create and encrypt a JWE.
>>>> Please do let me know if you find something else.
>>>>
>>>> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed <farasa...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Friday, February 9, 2018, Vihanga Liyanage <viha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> [- Engineering, Strategy]
>>>>>> [+ Architecture, Dev]
>>>>>>
>>>>>> Thanks,
>>>>>> Vihanga
>>>>>>
>>>>>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage <viha...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Farasath,
>>>>>>>
>>>>>>> For the above two points IMO it would be better to provide an option
>>>>>>>> at Service Provider OAuth/OIDC configuration. This will be similar to 
>>>>>>>> what
>>>>>>>> we have done for SAML.
>>>>>>>>
>>>>>>>
>>>>>>> That is the initial idea came to me as well. But shouldn't the
>>>>>>> clients have a choice of deciding that as well? May be through a request
>>>>>>> parameter. To use either JWS or JWE, the client have to support them 
>>>>>>> right?
>>>>>>>
>>>>>>
>>>>> By enabling the option to encrypt id_token in th

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

"Encryption Method" is the correct term/word here? AFAIK It's cipher
chaining mode. I know it's a technical word, but still, I feel like we have
to use correct naming. Something  like "Chaning Mode".


Thanks
Godwin

On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage  wrote:

> Hi all,
>
> [Update]
> I have completed the second phase of the project, providing service
> provider level configurations in admin dashboard to configure encryption
> algorithm and encryption method. With this update, once you enable
> encrypting id tokens for an SP in the admin dashboard, two select boxes
> will appear with supported encryption algorithms and supported encryption
> methods. These supported algorithms are pulled from the identity.xml file.
>
>
>
> Respective git issue and pull requests are as follows.
>
>- https://github.com/wso2/product-is/issues/2387
>- https://github.com/wso2/carbon-identity-framework/pull/1416
>- https://github.com/wso2-extensions/identity-inbound-
>auth-oauth/pull/832
>
> I have also updated the docs as well.
>
> Thanks,
> Vihanga.
>
> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> [Update]
>> I was able to complete the initial development of the proposed project,
>> encrypted id token support in OIDC flow. Following are the links related to
>> the development.
>>
>>- An issue was created in product-is repository to track the
>>development.
>>   - https://github.com/wso2/product-is/issues/2336
>>- Pull request is made to identity-inbound-auth-oauth repository with
>>required updates.
>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>   th/pull/798
>>- Pull request is made to product-is repository with updated
>>playground application to test the feature
>>- https://github.com/wso2/product-is/pull/2313
>>- Code review was held to review the code written in both PRs.
>>
>> All PRs are merged by now.
>> Currently, I'm working on integration test to test the newly added
>> feature.
>>
>> Thanks,
>> Vihanga
>>
>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Yes, Farasath. As for the offline discussions with Drashana, I came to
>>> the same conclusion and exploring the SAML sample app right now.
>>>
>>> Although I'm not sure about signing JWE. I couldn't find anything
>>> specific about that in the RFC. Also, the API in Nimbus only expects the
>>> claims set and the public key of the client to create and encrypt a JWE.
>>> Please do let me know if you find something else.
>>>
>>> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
>>> wrote:
>>>


 On Friday, February 9, 2018, Vihanga Liyanage  wrote:

> [- Engineering, Strategy]
> [+ Architecture, Dev]
>
> Thanks,
> Vihanga
>
> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
> wrote:
>
>> Hi Farasath,
>>
>> For the above two points IMO it would be better to provide an option
>>> at Service Provider OAuth/OIDC configuration. This will be similar to 
>>> what
>>> we have done for SAML.
>>>
>>
>> That is the initial idea came to me as well. But shouldn't the
>> clients have a choice of deciding that as well? May be through a request
>> parameter. To use either JWS or JWE, the client have to support them 
>> right?
>>
>
 By enabling the option to encrypt id_token in the service provider
 configs the client is acknowledging that it can support encrypted
 id_tokens.

 AFAIK even for JWE we need to first sign and then encrypt. Also I
 couldn't find any reference on a standard approach to allow clients to
 switch between JWS and JWE via a request parameter.

 If we take a look at how we handle this is SAML, we have an option in
 the SAML configs to say whether the assertion needs to be encrypted or not.
 Once the option to encrypt assertion is enabled SAML assertions will always
 be encrypted for the particular service provider (ie. There is no
 requirement to switch between signed or encrypted assertions)

 IMO we can follow the same approach. WDYT?


>>> On a separate note, any specific reason why we are discussing this
>>> in strategy and not in Dev and architecture mailing lists?
>>>
>>> I feel that we need to discuss this feature in architecture mailing
>>> list to get the input from community.
>>>
>>
>> No such specific reason at all. On the previous project I did, the
>> mail was asked to sent to engineering and strategy. So I followed the 
>> same
>> protocol. I'll change that now.
>>
>>>
>>>

 Thanks,
 Vihanga.

 --

 Vihanga Liyanage

 Software Engineer | WS*O₂* Inc.

 M : +*94710124103* | 

Re: [Architecture] [IS] OIDC SSO Agent for .NET

[Godwin Shrimal]

You have used word "SAML" in your mail and diagram, I hope it should be
OIDC.


Thanks
Godwin

On Wed, Feb 28, 2018 at 5:54 PM, Chiran Wijesekara  wrote:

> Architecture Diagram is attached below.
>
>
> On Wed, Feb 28, 2018 at 5:45 PM, Chiran Wijesekara 
> wrote:
>
>> *Introduction:*
>>
>> Suppose you have an ASP.NET web application or else you are going to
>> create a new one. One of your major concerns would be to provide a secure
>> mechanism of handling user authentication and authorization. With the
>> introduction of this OIDC SSO Agent, you will never have to worry about
>> that at all. Moreover, you can just incorporate this agent to your
>> ASP.NET web application and it will take care of all the things related
>> to OIDC authentication mechanism.
>>
>>
>> *Architecture:*
>>
>>
>>
>> 2, 3, 7, 8 are related to resolving of the current request.
>>
>>
>> How to incorporate to your asp.net web application?
>>
>> If you plan to use OIDC SSO Agent, all you have to do is following simple
>> steps below and then you have a web application that authenticates users
>> with your favourite Identity Provider ( Wso2 Identity Server).
>>
>> Let’s get started. The process of incorporating SAML authentication with
>> wso2 identity server via SAML agent can be explained in  6 steps.
>>
>>1.
>>
>>Add the agent.dll reference to your Asp.NET web application(You can
>>get this the git repo)
>>
>>
>>
>>1.
>>
>>Configure - the mandatory properties in your ASP.NET web
>>application’s web.config file. Following image shows how does it looks 
>> like
>>after adding those properties to your web.config file.
>>
>>
>>
>> Property
>>
>> Description
>>
>> Default Value
>>
>> EnableOIDCSSOLogin
>>
>> Enable OIDC authentication
>>
>> false
>>
>> OIDCSSOURL
>>
>> SSO URL
>>
>> oidcsso
>>
>> OIDC.spName
>>
>> Service Provider Identifier
>>
>> null
>>
>> OIDC.ClientId
>>
>> Client key which was generated during OIDC configuration for Service
>> Provider
>>
>> null
>>
>> OIDC.ClientSecret
>>
>> Client Secret which was generated during OIDC configuration for Service
>> Provider
>>
>> null
>>
>> OIDC.CallBackUrl
>>
>> Callback URL
>>
>> null
>>
>> OIDC.GrantType
>>
>> Grant Type
>>
>> code
>>
>> OIDC.AuthorizeEndpoint
>>
>> Authorization Endpoint of the IDP which is used to get an authorization
>> code.
>>
>> https://localhost:9443/oauth2/authorize
>>
>>
>> OIDC.TokenEndpoint
>>
>> Token endpoint of the IDP used to receive an access token
>>
>> https://localhost:9443/oauth2/token
>>
>>
>> OIDC.UserInfoEndpoint
>>
>> User info endpoint of the IDP which is used to fetch user details
>>
>> https://localhost:9443/oauth2/userinfo?schema=openid
>>
>>
>> OIDC.Scope
>>
>> Scope of the request as per the OIDC spec
>>
>> openid
>>
>> OIDC.EnableSLO
>>
>> Enable single logout
>>
>> OIDC.SLOURL
>>
>> Single logout URL
>>
>> oidclogout
>>
>> OIDC.EnableIDTokenValidation
>>
>> Enable ID token validation
>>
>> false
>>
>> OIDC.PostLogoutRedirectUri
>>
>> Post logout redirect URL
>>
>> null
>>
>> OIDC.SessionIFrameEndpoint
>>
>> OP Session IFrame Endpoint
>>
>> null
>>
>>
>> Below is a sample to demonstrate this step. You can edit the values as
>> per needed:
>>
>> 
>>
>>
>>
>>
>>
>>http://localhost:58521/
>> music-store/callback" />
>>
>>https://localhost:9443/
>> oauth2/authorize" />
>>https://localhost:9443/
>> oauth2/token" />
>>>
>> value="https://localhost:9443/oauth2/userinfo?schema=openid;
>> />
>>
>>
>>https://localhost:9443/; />
>>
>>
>>
>>>
>> value="http://localhost:58521/music-store/Default; />
>>>
>> value="https://localhost:9443/oidc/checksession; />
>>  
>>
>>
>>1.
>>
>>Next, if you want to validate ID token signature,  you need to have a
>>valid certificate. [Note: It is highly recommended to use your own
>>PKCS12 in your production environment].
>>
>> For testing purposes you can get the wso2carbon.jks from the wso2
>> Identity server ( / repository/ resources/ security/
>> wso2carbon.jks) and convert it to a PKCS12 using keytool utility. Then,
>> add the .p12 to the Local Machine certificate Store. However, below steps
>> guide you through the process which was described above.
>>
>>-
>>
>>You get keytool by default with java installation and it could be
>>found under the directory: C:\Program Files\Java\jre\bin , with
>>the name keytool.exe .
>>-
>>
>>You can use the below command to convert the wso2carbon.jks to
>>wso2carbon.p12
>>
>> keytool -importkeystore -srckeystore wso2carbon.jks -destkeystore
>> wso2carbon.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass
>> [PASSWORD_PKCS12]
>>
>>-
>>
>>Then, run microsoft management console( i.e: mmc.exe) as
>>administrator, menu File -> Add/Remove Snap-in.., select
>>"Certificates", press Add, select radio button "Computer account", and 
>> then
>>

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Godwin Shrimal]

Thanks for the explanation Rushmin. Yeah, it makes sense. +1


Thanks
Godwin

On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando <rush...@wso2.com> wrote:

> Hi Godwin,
>
> IMO certificate is a first class member of a service provider. So storing
> it as a field in SP_APP is cleaner.
>
> On the other hand, the datatype of a certificate doesn't really go with
> other metadata.
>
> In the best case, we have to alter the metadata table to hold a VARCHAR of
> like 1000 characters.
>
> Considering all of these facts, I thought of using the SP_APP table
> instead of SP_METADATA.
>
> What do you think?
>
> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi Rushmin,
>>
>> Any reason to use SP_APP table to persist the certificate? We have a
>> table called SP_METADATA to SP related metadata. I think we can use that
>> table without changing any DB Schema. WDYT?
>>
>>
>> Thanks
>> Godwin
>>
>> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando <rush...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne <is...@wso2.com>
>>> wrote:
>>>
>>>> Hi Rushmin,
>>>>
>>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>>>> hasan...@wso2.com> wrote:
>>>>
>>>>> Hi Rushmin,
>>>>>
>>>>> *How is this done now?*
>>>>>>
>>>>>> The application certificate should be imported to the keystore file
>>>>>> and the alias should be mentioned in the service provider so that the 
>>>>>> service
>>>>>> provider can validate the signature against the certificate identified
>>>>>> by that alias.
>>>>>>
>>>>>
>>>>> If we have the current option of  importing the certificate to the
>>>>> keystore, in JWT client authentication [1] we have to provide the
>>>>> certificate alias as the client id inorder to identify the application. So
>>>>> with this implementation we don't need to enforce end users to do the 
>>>>> above
>>>>> as we can fetch the client_id directly from the db.
>>>>>
>>>>> +1 for the approach.
>>>>>
>>>>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando <rush...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> In the identity server, a service provider represents the application
>>>>>> which uses the Identity Server as an Identity Provider.
>>>>>>
>>>>>> In some cases, Identity Server needs to validate the identity of the
>>>>>> application to make sure the authentication/authorization requests are
>>>>>> coming from the legitimate application.
>>>>>>
>>>>>> *How is this done now?*
>>>>>>
>>>>>> The application certificate should be imported to the keystore file
>>>>>> and the alias should be mentioned in the service provider so that the
>>>>>> service provider can validate the signature against the certificate
>>>>>> identified by that alias.
>>>>>>
>>>>>> *Why is this needs to be improved?*
>>>>>>
>>>>>> 1) keystore file resides in the file system. Therefore in a clustered
>>>>>> deployment, either the certificate should be added to all the nodes or 
>>>>>> the
>>>>>> keystore file should be synced.
>>>>>>
>>>>>> 2) The server needs a restart after importing a certificate.
>>>>>>
>>>>>> *What is the solution?*
>>>>>>
>>>>>> The certificate should be stored in the database so that it is shared
>>>>>> and a restart is not needed.
>>>>>>
>>>>>> *High-level design/UX decisions*
>>>>>>
>>>>>> 1) The SP UI will have a new text area to enter the certificate in
>>>>>> PEM format.
>>>>>>
>>>>> Is there any specific reason to use text area here? In IDP UI, we have
>>>> an option to upload the idp cert. IMO it is better to have that option in
>>>> SP U

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Godwin Shrimal]

Hi Rushmin,

Any reason to use SP_APP table to persist the certificate? We have a table
called SP_METADATA to SP related metadata. I think we can use that table
without changing any DB Schema. WDYT?


Thanks
Godwin

On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando  wrote:

>
>
> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne  wrote:
>
>> Hi Rushmin,
>>
>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi Rushmin,
>>>
>>> *How is this done now?*

 The application certificate should be imported to the keystore file
 and the alias should be mentioned in the service provider so that the 
 service
 provider can validate the signature against the certificate identified
 by that alias.

>>>
>>> If we have the current option of  importing the certificate to the
>>> keystore, in JWT client authentication [1] we have to provide the
>>> certificate alias as the client id inorder to identify the application. So
>>> with this implementation we don't need to enforce end users to do the above
>>> as we can fetch the client_id directly from the db.
>>>
>>> +1 for the approach.
>>>
>>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>>
>>> Thanks,
>>>
>>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
>>> wrote:
>>>

 In the identity server, a service provider represents the application
 which uses the Identity Server as an Identity Provider.

 In some cases, Identity Server needs to validate the identity of the
 application to make sure the authentication/authorization requests are
 coming from the legitimate application.

 *How is this done now?*

 The application certificate should be imported to the keystore file and
 the alias should be mentioned in the service provider so that the service
 provider can validate the signature against the certificate identified by
 that alias.

 *Why is this needs to be improved?*

 1) keystore file resides in the file system. Therefore in a clustered
 deployment, either the certificate should be added to all the nodes or the
 keystore file should be synced.

 2) The server needs a restart after importing a certificate.

 *What is the solution?*

 The certificate should be stored in the database so that it is shared
 and a restart is not needed.

 *High-level design/UX decisions*

 1) The SP UI will have a new text area to enter the certificate in PEM
 format.

>>> Is there any specific reason to use text area here? In IDP UI, we have
>> an option to upload the idp cert. IMO it is better to have that option in
>> SP UI as well for the UI consistance.
>>
>
> It is bit easier for users to paste the content staight away rather than
> uploading files.
>
> +1 for making both UIs consistent.
>
>
>> Thanks
>> Isura.
>>
>>>
 2) The certificate will be stored in the SP_APP table. A new column
 will be added.

 *REASON*:

 Service provider --> certificate is a 1:1 relationship.

 3) An interface will be introduced to abstract out the certificate
 handling of the SP. Two implementations will be there to support the
 current behavior and the proposed behavior.

 4) Current behavior will be deprecated.

 5) Choosing between the two implementations not explicit for the users,
 so a configuration will not be provided. If a certificate is not available
 in the database Identity Server will fall back to the current approach.

 *REASON*:

 1. This feature is about changing an internal implementation. So the
 users should not worry about it.



 Please share your thoughts.




 --
 *Best Regards*

 *Rushmin Fernando*
 *Technical Lead*

 WSO2 Inc.  - Lean . Enterprise . Middleware

 mobile : +94775615183



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>>
>>> Hasanthi Dissanayake
>>>
>>> Senior Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead

Re: [Architecture] What is the most suitable way to invoke DCR endpoints from native mobile application

[Godwin Shrimal]

Hi Gayan,

+1 for option 3. Securing data in the mobile device is a vendor-specific
thing. You can find some information in [1] about android data security.

[1] https://developer.android.com/training/articles/security-tips.html

Thanks
Godwin

On Mon, Dec 18, 2017 at 2:50 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> In Identity Server DCR endpoints are secured with pluggable security layer
> where we can use Basic Authentication, Oauth, Certificate based
> authentication and any custom authentication. We have below evaluation on
> each method
>
> 1. Basic Authentication: From security perspective its clearly not
> applicable to embed super tenant or tenant credentials into native
> application. What is feasible here is to take end user credentials in run
> time and invoke DCR end point with end user credentials (need to set
> correct user permission to invoke DCR end point)
>
> 2. Certificate based Authentication: This is a good option but have few
> problems how to distribute certificate and also other application can
> access key chain which will be a security vulnerability (need to check with
> mobile expert)
>
> 3. Oauth based Authentication: Securing DCR endpoint with initial access
> token is a practice coming from DCR specification but the problem is how to
> store this initial access token securely in mobile application.
>
> WDYT?
>
> Thanks,
> Gayan
>
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/
*
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C4[]APIM] REST API for changing Owner of a Application

[Godwin Shrimal]

Hi Sam,

Who can change the owner of the application?

Thanks
Godwin


On Sun, Dec 17, 2017 at 7:56 AM, Sam Sivayogam  wrote:

> Hi All,
>
> As discussed in mail thread[1] we had a requirement to add an API which
> allows to change the owner of a created application. During the initial
> discussions we decided to add this api to the existing admin REST APIs.
> After going through the APIs I thought to add below 2 resources.
>
>
> 1. The following GET resource will list all the apis created by the given
> user. This will be same as the store application listing API but lists
> application for the given username rather than listing the applications
> created user associated with the provided access token.
>
> This will return the
> GET  /applications
>
> Parameters
> query username
>
>
> Sample Response :
> {
>"count": 2,
>"next": "",
>"previous": "",
>"list":[
> {
>  "applicationId": "b16ce8d0-5e0b-4259-96e2-68151cc92489",
>  "name": "AppX",
>  "subscriber": "admin",
>  "throttlingTier": "Unlimited",
>  "description": "",
>  "status": "APPROVED",
>  "groupId": ""
>   },
> {
>  "applicationId": "aac0df98-8e26-4dda-b0ba-d794c98249c2",
>  "name": "AppY",
>  "subscriber": "admin",
>  "throttlingTier": "Unlimited",
>  "description": null,
>  "status": "APPROVED",
>  "groupId": ""
>   }
>]
> }
>
>
> 2. Following POST Resource is similar to the one we have for lifecycle
> change. This will change the owner of the given application
> POST /applications/change-owner
>
> Parameters
> query application UUID
> query newOwner
>
> Sample Response :
>
> {
>"applicationId": "6edcac5e-4df3-42fe-8a21-07c114085bcb",
>"name": "AppY",
>"subscriber": "newOwner",
>"throttlingTier": "Unlimited",
>"callbackUrl": null,
>"description": "",
>"status": "APPROVED",
>"groupId": ""
> }
>
> Please let me know your thoughts on this.
>
> [1] Application Sharing support for Multiple Groups
>
> Thanks,
> Sam
>
>
> --
> *Sam Sivayogam*
>
> Senior Software Engineer
> Mobile  : +94 772 906 439
> Office   : +94 112 145 345
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>



-- 
*Godwin Amila Shrimal*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/
*
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Godwin Shrimal]

Hi Johan,


On Tue, Nov 7, 2017 at 8:38 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> Hi Godwin,
>
> On Tue, Nov 7, 2017 at 7:51 PM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi Johan,
>>
>>
>> On Tue, Nov 7, 2017 at 7:33 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Hi Godwin,
>>>
>>> On Tue, Nov 7, 2017 at 7:11 PM, Godwin Shrimal <god...@wso2.com> wrote:
>>>
>>>> Hi Johann,
>>>>
>>>> Yes, these are not connectors but don't we need to follow the same
>>>> naming convention for these repos as well?
>>>>
>>>
>>> There are many other repos under wso2-extensions that don't follow this
>>> convention. My understanding is this convention is only suitable for
>>> authenticators and provisioning connectors. Not for the rest. E.g.
>>> identity-metadata-saml2, identity-data-publisher-authentication,
>>> identity-governance, and many more. Similarly for userstore connectors we
>>> have "identity-userstore-" convention. This is what I understood. If others
>>> think different please holler.
>>>
>>
>> In your examples identity-*metadata*-saml2, identity-*data-publisher*
>> -authentication, "identity-*userstore*-" (except identity-governance)
>> also follows the pattern.
>>
>
> Yes, we can follow some other naming convention if needed. I thought you
> were saying to follow same naming convention as provisioning connectors.
>

I am not clear why don't we follow the same naming convension and what are
the advantages of not using it and what are the disadvantage of using it,
By using same naming convension it enhance the readability and if we know
the naming convention we can clearly understand what is this repo for.


>
>>
>>> Let me try to put it in another way :). Once we have the 3 repos, the
>>> identity-client-scim2 repo will depend on the identity-scim2-common repo.
>>> Both these repos together can be used outside the IS product as well,
>>> purely as a client side library for scim2. Having the word "provisioning"
>>> in the middle would mean (according to my understanding of our convention)
>>> this is purely a connector for IS and has no business outside the scope of
>>> IS, which is not true.
>>>
>>
>> I am not totally aggree with this, then *"identity*-" prefix also give
>> the same feeling that's purely for IS conenctors weather we use
>> provisioning word or not. So I don't see any difference for using outside
>> the IS product with/without using "provisioning" word.
>>
>
> The word "identity" is to indicate that these are from identity domain.
> E.g. we have 5 repos starting as "identity-agent-", which are all agents
> that work outside IS, but in identity domain. "identity" doesn't mean it is
> in IS product.
>

If word "*identity*-" gives the perception its related to identity domain
not only for IS product, I think same applies to word "*provisioning*".
WDYT ?


>
> Regards,
> Johann.
>
>
>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>> Thanks
>>>> Godwin
>>>>
>>>>
>>>> On Tue, Nov 7, 2017 at 6:40 PM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Godwin,
>>>>>
>>>>> On Tue, Nov 7, 2017 at 6:02 PM, Godwin Shrimal <god...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Johan,
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby <joh...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Maheshika,
>>>>>>>
>>>>>>> Can we have following 3 repos for this project under wso2-extensions
>>>>>>> organization?
>>>>>>>
>>>>>>> 1. *identity-outbound-provisioning-scim2*
>>>>>>>
>>>>>>> For the outbound connector
>>>>>>>
>>>>>>> 2. *identity-scim2-common*
>>>>>>>
>>>>>>> don't we need to keep the grouping name in the repo as
>>>>>> *identity-provisioning-scim2-common*
>>>>>>
>>>>>
>>>>> My understanding is the parts "auth" and "provisioning" in the repo
>>>>> names, refer t

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Godwin Shrimal]

Hi Johan,


On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby  wrote:

> Hi Maheshika,
>
> Can we have following 3 repos for this project under wso2-extensions
> organization?
>
> 1. *identity-outbound-provisioning-scim2*
>
> For the outbound connector
>
> 2. *identity-scim2-common*
>
> don't we need to keep the grouping name in the repo as
*identity-provisioning-scim2-common*



> For common utilities for inbound and outbound connectors. E.g.
> AttributeMapper class in inbound connector which is needed for outbound
> connector as well.
>
> 3. *identity-client-scim2*
>
> Isn't this should be *identity-provisioning-scim2-*
*client *


> For SCIM2 client generated using SCIM2 swagger files. This will be used by
> outbound connector as well as can be used by anyone as standalone client.
> Ideally this should be used for the scim2 compliance test suite as well,
> but have failed to do so.
>
> Regards,
> Johann.
>
> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby 
> wrote:
>
>> Yes, I also think we need to take the approach of using the Swagger files
>> and generate SDK because that is what standard Rest API world will be
>> doing. We can find any issues early.
>>
>> Regards,
>> Johann.
>>
>> On Mon, Oct 16, 2017 at 2:18 PM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 16, 2017 at 1:21 PM, Isuranga Perera <
>>> isurangamper...@gmail.com> wrote:
>>>
 Hi Gayan,

 In that case, I'll try to create an SDK from swagger and use it as the
 client.

>>> That would be great.
>>>

 Best Regards

 On Mon, Oct 16, 2017 at 9:12 AM, Gayan Gunawardana 
 wrote:

> Since you are looking for abstraction layer, can implement something
> like [1] for SCIM2 as well.
>
> [1] https://github.com/wso2-extensions/identity-inbound-provisio
> ning-scim/blob/master/components/org.wso2.carbon.identity.sc
> im.common/src/main/java/org/wso2/carbon/identity/scim/common
> /impl/ProvisioningClient.java
>
> On Sun, Oct 15, 2017 at 11:16 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Sun, Oct 15, 2017 at 8:39 PM, Johann Nallathamby 
>> wrote:
>>
>>> *[+ IsharaK, Omindu, Farasath]*
>>>
>>> On Sun, Oct 15, 2017 at 7:34 PM, Isuranga Perera <
>>> isurangamper...@gmail.com> wrote:
>>>
 Hi,

 I went through the scim2-compliance-test-suite [1] source code,
 but I couldn't find an abstraction layer which separates the SCIM 2 
 client
 from the test and report modules. Is there any way I can separate SCIM 
 2.0
 client from [1] so that I can use it as the SCIM 2.0 client for the
 $subject.

>>> There is no clear abstraction layer. Both SCIM2 compliance test
>> developed by Vindula and SCIM 1.1 outbound provisioning connector are
>> utilized apache commons http client .
>>
>>>
 In addition to that, I found this[2] repository which contains
 another SCIM client. can I know the completion level of this project?

>>> This is feign http client and Vindula found it hard to use.
>>
>>>
 In summary, there are 3 options which I can use to generate a SCIM
 2.0 client.

>>> Most feasible way is to go with apache commons HttpClient  but
>> better to give a try with swagger doc as well.
>>
>>>

1. Separate SCIM 2.0 client from [1]
2. Separate SCIM 2.0 client from [2]
3. Use swagger doc [3] to generate client


 [1] https://github.com/wso2-incubator/scim2-compliance-test-suite
 [2] https://github.com/HansageeSJ/scim-client
 [3] https://wso2.org/jira/browse/IDENTITY-5695

 Appreciate any suggestions.


 Best Regards
 Isuranga Perera

 On Fri, Oct 13, 2017 at 9:42 AM, Gayan Gunawardana 
 wrote:

>
>
> On Thu, Oct 12, 2017 at 5:33 PM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>>
>>
>> On Thu, Oct 12, 2017 at 1:28 PM, Isuranga Perera <
>> isurangamper...@gmail.com> wrote:
>>
>>> Hi IAM Team,
>>>
>>
>>> Currently, there is no $subject. Therefore I'm looking at
>>> implementing a SCIM2 Outbound Connector. I'm looking at
>>> identity-outbound-provisioning-scim [1]
>>> and scim2-compliance-test-suite [2]. Appreciate further
>>> suggestions.
>>>
>> Hi Isuranga,
>
> It should be same as [1] you just have to think SCIM provider is
> version 2 and send http requests according to SCIM2 format. As a 
> starting
> point you can setup existing SCIM provisioning connector and debug 
> 

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Godwin Shrimal]

Hi Johan,


On Tue, Nov 7, 2017 at 7:33 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> Hi Godwin,
>
> On Tue, Nov 7, 2017 at 7:11 PM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi Johann,
>>
>> Yes, these are not connectors but don't we need to follow the same naming
>> convention for these repos as well?
>>
>
> There are many other repos under wso2-extensions that don't follow this
> convention. My understanding is this convention is only suitable for
> authenticators and provisioning connectors. Not for the rest. E.g.
> identity-metadata-saml2, identity-data-publisher-authentication,
> identity-governance, and many more. Similarly for userstore connectors we
> have "identity-userstore-" convention. This is what I understood. If others
> think different please holler.
>

In your examples identity-*metadata*-saml2,
identity-*data-publisher*-authentication,
"identity-*userstore*-" (except identity-governance) also follows the
pattern.


> Let me try to put it in another way :). Once we have the 3 repos, the
> identity-client-scim2 repo will depend on the identity-scim2-common repo.
> Both these repos together can be used outside the IS product as well,
> purely as a client side library for scim2. Having the word "provisioning"
> in the middle would mean (according to my understanding of our convention)
> this is purely a connector for IS and has no business outside the scope of
> IS, which is not true.
>

I am not totally aggree with this, then *"identity*-" prefix also give the
same feeling that's purely for IS conenctors weather we use provisioning
word or not. So I don't see any difference for using outside the IS product
with/without using "provisioning" word.


> Regards,
> Johann.
>
>
>> Thanks
>> Godwin
>>
>>
>> On Tue, Nov 7, 2017 at 6:40 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Hi Godwin,
>>>
>>> On Tue, Nov 7, 2017 at 6:02 PM, Godwin Shrimal <god...@wso2.com> wrote:
>>>
>>>> Hi Johan,
>>>>
>>>>
>>>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Maheshika,
>>>>>
>>>>> Can we have following 3 repos for this project under wso2-extensions
>>>>> organization?
>>>>>
>>>>> 1. *identity-outbound-provisioning-scim2*
>>>>>
>>>>> For the outbound connector
>>>>>
>>>>> 2. *identity-scim2-common*
>>>>>
>>>>> don't we need to keep the grouping name in the repo as
>>>> *identity-provisioning-scim2-common*
>>>>
>>>
>>> My understanding is the parts "auth" and "provisioning" in the repo
>>> names, refer to the kind of connectors. This particular repo is not a
>>> connector repo per se, but a dependency to the connector. I think this name
>>> is fine.
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>> For common utilities for inbound and outbound connectors. E.g.
>>>>> AttributeMapper class in inbound connector which is needed for outbound
>>>>> connector as well.
>>>>>
>>>>> 3. *identity-client-scim2*
>>>>>
>>>>> Isn't this should be *identity-provisioning-scim2-*
>>>> *client *
>>>>
>>>
>>> Again same explanation as above.
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>>
>>>>
>>>>> For SCIM2 client generated using SCIM2 swagger files. This will be
>>>>> used by outbound connector as well as can be used by anyone as standalone
>>>>> client. Ideally this should be used for the scim2 compliance test suite as
>>>>> well, but have failed to do so.
>>>>>
>>>>> Regards,
>>>>> Johann.
>>>>>
>>>>> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby <joh...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Yes, I also think we need to take the approach of using the Swagger
>>>>>> files and generate SDK because that is what standard Rest API world will 
>>>>>> be
>>>>>> doing. We can find any issues early.
>>>>>>
>>>>>> Regards,
>>>>>> Johann.
>>>>>>
>>>>>> On Mon, Oct 16, 2017 at 2:18 PM, Ga

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Godwin Shrimal]

Hi Johann,

Yes, these are not connectors but don't we need to follow the same naming
convention for these repos as well?

Thanks
Godwin


On Tue, Nov 7, 2017 at 6:40 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> Hi Godwin,
>
> On Tue, Nov 7, 2017 at 6:02 PM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi Johan,
>>
>>
>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Hi Maheshika,
>>>
>>> Can we have following 3 repos for this project under wso2-extensions
>>> organization?
>>>
>>> 1. *identity-outbound-provisioning-scim2*
>>>
>>> For the outbound connector
>>>
>>> 2. *identity-scim2-common*
>>>
>>> don't we need to keep the grouping name in the repo as
>> *identity-provisioning-scim2-common*
>>
>
> My understanding is the parts "auth" and "provisioning" in the repo names,
> refer to the kind of connectors. This particular repo is not a connector
> repo per se, but a dependency to the connector. I think this name is fine.
>
>
>>
>>
>>
>>
>>> For common utilities for inbound and outbound connectors. E.g.
>>> AttributeMapper class in inbound connector which is needed for outbound
>>> connector as well.
>>>
>>> 3. *identity-client-scim2*
>>>
>>> Isn't this should be *identity-provisioning-scim2-*
>> *client *
>>
>
> Again same explanation as above.
>
> Regards,
> Johann.
>
>
>>
>>
>>> For SCIM2 client generated using SCIM2 swagger files. This will be used
>>> by outbound connector as well as can be used by anyone as standalone
>>> client. Ideally this should be used for the scim2 compliance test suite as
>>> well, but have failed to do so.
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Yes, I also think we need to take the approach of using the Swagger
>>>> files and generate SDK because that is what standard Rest API world will be
>>>> doing. We can find any issues early.
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>> On Mon, Oct 16, 2017 at 2:18 PM, Gayan Gunawardana <ga...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 16, 2017 at 1:21 PM, Isuranga Perera <
>>>>> isurangamper...@gmail.com> wrote:
>>>>>
>>>>>> Hi Gayan,
>>>>>>
>>>>>> In that case, I'll try to create an SDK from swagger and use it as
>>>>>> the client.
>>>>>>
>>>>> That would be great.
>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> On Mon, Oct 16, 2017 at 9:12 AM, Gayan Gunawardana <ga...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Since you are looking for abstraction layer, can implement something
>>>>>>> like [1] for SCIM2 as well.
>>>>>>>
>>>>>>> [1] https://github.com/wso2-extensions/identity-inbound-provisio
>>>>>>> ning-scim/blob/master/components/org.wso2.carbon.identity.sc
>>>>>>> im.common/src/main/java/org/wso2/carbon/identity/scim/common
>>>>>>> /impl/ProvisioningClient.java
>>>>>>>
>>>>>>> On Sun, Oct 15, 2017 at 11:16 PM, Gayan Gunawardana <ga...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Oct 15, 2017 at 8:39 PM, Johann Nallathamby <
>>>>>>>> joh...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> *[+ IsharaK, Omindu, Farasath]*
>>>>>>>>>
>>>>>>>>> On Sun, Oct 15, 2017 at 7:34 PM, Isuranga Perera <
>>>>>>>>> isurangamper...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I went through the scim2-compliance-test-suite [1] source code,
>>>>>>>>>> but I couldn't find an abstraction layer which separates the SCIM 2 
>>>>>>>>>> client

Re: [Architecture] [EI] Dynamically Routing Messages to Message Stores

[Godwin Shrimal]

Hi Thishani,

Can we support property such as below?



Thanks
Godwin


On Mon, Sep 18, 2017 at 12:08 PM, Thishani Lucas  wrote:

> Hi Maninda,
>
> Thank you for your suggestion. Yes i thought of following Property
> Mediator. But instead of introducing a new attribute called 'expression'
> like in the Property Mediator, I plan to allow the Store Mediator to take
> both the path expression and the string value. Then we can have a logic to
> differentiate between a hard-coded store name and a path expression i.e if
> the value is enclosed by curly braces, then it is an expression. This way we
> can maintain the backward compatibility.
>
> Thank you.
>
> On Mon, Sep 18, 2017 at 11:39 AM, Maninda Edirisooriya 
> wrote:
>
>> Hi Thishani,
>>
>> You can follow the same way the expressions/values spacified in Property
>> Mediator in [1]. Then it will maintain the consistency in ESB space and you
>> can simply reusing the existing functionality.
>>
>> [1] https://docs.wso2.com/display/ESB500/Property+Mediator
>>
>> Thanks.
>>
>>
>> *Maninda Edirisooriya*
>> Senior Software Engineer
>>
>> *WSO2, Inc.*lean.enterprise.middleware.
>>
>> *Blog* : http://maninda.blogspot.com/
>> *E-mail* : mani...@wso2.com
>> *Skype* : @manindae
>> *Twitter* : @maninda
>>
>> On Mon, Sep 18, 2017 at 10:37 AM, Thishani Lucas 
>> wrote:
>>
>>> The current store mediator implementation allows the name of the message
>>> store to which the messages should be sent, to be given as a hard-coded
>>> string value. The requirement is to route the messages dynamically i.e
>>> without giving the hard-coded name, derive the name from the message
>>> context. To enable this, the message store name attribute of the store
>>> mediator should be allowed to take a path expression as a value. But also
>>> there should be a way to differentiate between a string value and an
>>> expression.
>>>
>>> According to the existing implementation, the store mediator is defined
>>> as follows.
>>>
>>> 
>>>
>>> But with my implementation, the user will be able to extract the name
>>> from the message context and set it to message store as shown below.
>>>
>>> 
>>>
>>> Please provide your suggestions on this feature.
>>>
>>> --
>>> Regards,
>>>
>>> *Thishani Lucas*
>>> *Software Engineer*
>>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>>> *lean.enterprise.middle-ware*
>>>
>>> *Tel: +94 77 2556931 <077%20255%206931> *
>>>
>>> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
>>> *
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Regards,
>
> *Thishani Lucas*
> *Software Engineer*
> *WSO2 Lanka (Private) Limited**: http://wso2.com *
> *lean.enterprise.middle-ware*
>
> *Tel: +94 77 2556931 <+94%2077%20255%206931> *
>
> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
> *
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Having separate keystore (private key) for each token signing in WSO2IS

[Godwin Shrimal]

+1 to have separate keystores for secure vault & token signing. Any
reason/use case to have separate kesytores for each token signing ? Will it
not add more overhead on deployment and maintenance ? With the custom
inbound authenticator feature you can plug your own inbound authenticator
and then we have to think which token signing keystore we use ?


Thanks
Godwin

On Wed, Apr 12, 2017 at 5:58 PM, Asela Pathberiya  wrote:

> Hi All,
>
> According to the current design;   KeyStore which is defined in the
> carbon.xml file is used for both secure vault & token signing
> (SAML/id_token) which is not a good design.  We need to keep that separate
> keystore for secure vault as it can not be modified.
>
> Also; To add more flexibility;  it is better to have separate keystore for
> each token signing.  I know we can extend & achieve this,  but default
> implementation would be great.
>
> Shall we add this to next WSO2IS release as this is a simple improvement ?
>
> Thanks,
> Asela.
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [IS 6.0.0] Delete Users UI for IS 6.0.0 Admin Portal

[Godwin Shrimal]

According to the wire-frame, each row has a delete button. Can you explain
how to delete multiple users at once ?

On Wed, Mar 29, 2017 at 9:41 PM, Ashen Weerathunga  wrote:

> Hi all,
>
> We are in the process of implementing delete user option in the admin
> portal for the IS 6.0.0 release. The wireframe design for the UI can be
> found at [1]. This will implement the following scenario.
>
>- Admin should be able to delete users individually as well as
>multiple users at once.
>- A confirmation pop-up message will be shown prior to the delete
>process.
>- If the action is successful, then it should be notified in the UI.
>- If the action is unsuccessful, then it should be notified in the UI.
>
> Appreciate any suggestions regarding this.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v4/3.36_Delete_user.png
>
> Thanks,
> Ashen
> --
> *Ashen Weerathunga*
> Software Engineer
> WSO2 Inc.: http://wso2.com
> lean.enterprise.middleware
>
> Email: as...@wso2.com
> Mobile: +94716042995 <94716042995>
> LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
> *
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Admin Initiated Password Reset by Reset Link

[Godwin Shrimal]

+1 to use wire frames as 'Admin Forced Password Reset' since if we use as
"Reset Password" it'll conflict with the user story which user him/her self
resetting their own password.

Shall we rename the label "Select password reset method" to something like
"How would you like to reset your password ?"


Thanks
Godwin

On Thu, Mar 23, 2017 at 11:51 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Minoli,
>
> Shall we update all the wire frames related to 'Admin Forced Password
> Reset'?. Can we use 'Save' instead of 'Reset' button for 'offline password
> reset option' [1] and use 'Send' for other two options, reset via link [2]
> and reset via Email OTP [3]?
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.31%20%20Reset%20password%20-%
> 20with%20offline%20OTP.png
> [2] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.35%20%20Reset%20password%
> 20with%20reset%20link.png
> [3] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.33%20%20Reset%20password%20-%
> 20with%20email%20OTP.png
>
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Thu, Mar 23, 2017 at 11:36 AM, Ayesha Dissanayaka 
> wrote:
>
>>
>> On Thu, Mar 23, 2017 at 11:26 AM, Dilan Udara Ariyaratne > > wrote:
>>
>>> So, can we term the title of the provided wire-frame as "Reset Password"
>>> and action button name as "Reset", because this UI is supposed to be used
>>> by an administrator
>>> to actually force a password reset action by some other user and not to
>>> reset his password ?
>>>
>> +1,
>>
>> @Hasanthi: As we already discussed such improvements to
>> wire-frames/wordings during the internal review, Can we get them updated as
>> well.
>>
>> --
>> *Ayesha Dissanayaka*
>> Senior Software Engineer,
>> WSO2, Inc : http://wso2.com
>> 
>> 20, Palm grove Avenue, Colombo 3
>> E-Mail: aye...@wso2.com 
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Email Verification for Existing User

[Godwin Shrimal]

What happen when user modify email or telephone number ? user have to
verify it back ?

Thanks
Godwin


On Tue, Mar 21, 2017 at 10:04 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Gayan,
>
> User Story :
>
>1. User chooses to verify email of an existing user.
>2. User selects if the user account must be locked until existing user
>verifies his email.
>
> *Acceptance Criteria*
>
>1. The existing user must receive an email.
>2. If the User Admin had chosen to lock the existing user account
>until email verification, then until the existing user confirms his/her
>email, he/she must not be able to login to the system using this account.
>3. If the action is successful, then it should be notified in the UI.
>4. If the action is unsuccessful, then it should be notified in the UI.
>5. User must be directed to the user listing page.
>
>
> Still the wire frames are not finalized and Minoli is updating it.
> Exisiting wireframes can be found from  [1] and [2]
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.27%20Edit%20user%20profile%20-
> %20verified%20state.png
> [2]https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.25%20Edit%20user%20profile%20-
> %20send%20verification.png
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Tue, Mar 21, 2017 at 9:48 AM, Gayan Gunawardana  wrote:
>
>>
>>
>> On Tue, Mar 21, 2017 at 9:09 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> I am going to implement the $subject according to the user story [1].
>>>
>> Please mention the user story and wire frame location.
>>
>>> According to the wire frame, when admin updates an existing user's
>>> details he has the option to verify the email address. There is an optional
>>> checkbox for the admin to decide whether the user account is locked or not
>>> untill the user verifies the email.  So if the User Admin had chosen to
>>> lock the existing user account until email verification, then until the
>>> existing user confirms his email he can not be able to login to the system
>>> by using his account.
>>>
>>> Highly appreciate any comments on this.
>>>
>>> Thanks,
>>>
>>> Hasanthi Dissanayake
>>>
>>> Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0][admin-portal] User Onboarding - Ask Password with email verification

[Godwin Shrimal]

Correction

1. As Isura mentioned we don't need to lock the account since we are
creating the user with random password no one knows it.

On Tue, Mar 21, 2017 at 10:06 AM, Godwin Shrimal <god...@wso2.com> wrote:

> Hi Dinali,
>
> Please see my feedback below.
>
> 1. As Isura mentioned we don't to lock the account since we are creating
> the user with random password on one knows it.
> 2. Can't we use name User store (or what ever the term use in C5) other
> than Domain, its not user friendly and end users will not aware what is
> Domain.
> 3. I guess combo box with available option is not user friendly and what
> about having option buttons which shows available options at once to user ?
>
>
> Thanks
> Godwin
>
>
> On Mon, Mar 20, 2017 at 5:53 PM, Dinali Dabarera <din...@wso2.com> wrote:
>
>> Hi All,
>>
>> I am going to implement User Onboarding - Ask Password with email
>> verification according to the User story [1].The wire-frame given by the UX
>> team is [2].
>>
>> According to these,
>>
>> *In admin side,*
>>
>>- The admin creates a user and put his email and click on Add user.
>>- Then an email is sent to the user's given email address.
>>- The admin will redirect to the List user page.
>>
>> *In users side*,
>>
>>- The user will get a link to set a password.
>>- The User can click on it and add a password.
>>
>> *There are two main concerns that am bothering about,*
>>
>>1. *When the user clicks the link, I think we can redirect to the
>>change password page in user portal. Is this fine or Do we need to use a
>>custom page for that?*
>>2. *I think we need to lock the account of that user Until he adds a
>>password. Is this necessary?*
>>
>>
>> [1] https://redmine.wso2.com/issues/5749
>> [2]https://github.com/wso2-dev-ux/product-is/blob/master/Wir
>> eframes/admin-portal/v3/3.5%20Add%20user%20with%20email%20
>> verification.png
>>
>> ​Thank you!​
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
>> Mobile: +94770198933 <+94%2077%20019%208933>
>>
>>
>>
>>
>> <https://lk.linkedin.com/in/dinalidabarera>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
> twitter: https://twitter.com/godwinamila
> <http://wso2.com/signature>
>



-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
twitter: https://twitter.com/godwinamila
<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0][admin-portal] User Onboarding - Ask Password with email verification

[Godwin Shrimal]

Hi Dinali,

Please see my feedback below.

1. As Isura mentioned we don't to lock the account since we are creating
the user with random password on one knows it.
2. Can't we use name User store (or what ever the term use in C5) other
than Domain, its not user friendly and end users will not aware what is
Domain.
3. I guess combo box with available option is not user friendly and what
about having option buttons which shows available options at once to user ?


Thanks
Godwin


On Mon, Mar 20, 2017 at 5:53 PM, Dinali Dabarera  wrote:

> Hi All,
>
> I am going to implement User Onboarding - Ask Password with email
> verification according to the User story [1].The wire-frame given by the UX
> team is [2].
>
> According to these,
>
> *In admin side,*
>
>- The admin creates a user and put his email and click on Add user.
>- Then an email is sent to the user's given email address.
>- The admin will redirect to the List user page.
>
> *In users side*,
>
>- The user will get a link to set a password.
>- The User can click on it and add a password.
>
> *There are two main concerns that am bothering about,*
>
>1. *When the user clicks the link, I think we can redirect to the
>change password page in user portal. Is this fine or Do we need to use a
>custom page for that?*
>2. *I think we need to lock the account of that user Until he adds a
>password. Is this necessary?*
>
>
> [1] https://redmine.wso2.com/issues/5749
> [2]https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.5%20Add%20user%20with%20email%
> 20verification.png
>
> ​Thank you!​
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0 - Admin Portal ] Edit User profile (Update User)

[Godwin Shrimal]

Hi Dinali,

Well, your earlier reply give impression it is validating the format of the
email and mobile number, If it is, that validation should happen
automatically (Ex. when lost focus of the input). I guess your last reply
is correct, which is sending a code via email or SMS and validate those
entries.


Thanks
Godwin

On Tue, Mar 14, 2017 at 11:55 AM, Dinali Dabarera <din...@wso2.com> wrote:

>
> Hi Godwin,
>
> Continuing the above email
> The function of the verify button click is done by this user story [1].
> Which is not done by me.
> At the moment we are not supporting mobile verification.
>
> Thanks
>
> [1] https://redmine.wso2.com/issues/5752
>
> On Tue, Mar 14, 2017 at 11:44 AM, Dinali Dabarera <din...@wso2.com> wrote:
>
>> Hi Godwin,
>>
>> Here, verify means it checks whether the updated value Is a type of email
>> (--@abc.com) or type of mobile number(10 numbers).
>> We can not check availability of email or mobile because one or more
>> users can have same email or same mobile number.
>>
>> Thanks!
>>
>> On Tue, Mar 14, 2017 at 10:56 AM, Godwin Shrimal <god...@wso2.com> wrote:
>>
>>> Hi Dinali,
>>>
>>> Can you explain what exactly happens when click on Verify button on
>>> email or phone number ? And how do you filter those claims and display
>>> those buttons ?
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>>
>>> On Tue, Mar 14, 2017 at 10:52 AM, Dinali Dabarera <din...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am implementing Edit User profile in the admin portal as designed in
>>>> [1]. I am using the same account settings profile used in user-portal to
>>>> implement this. I have started implementing UI part first and next moving
>>>> to back-end.
>>>> Since We have to use the same UUF components used in user-portal, I
>>>> will move the UUF components into one module called
>>>> org.wso2.carbon.iam.common-uuf for the m5 release.
>>>>
>>>> Please leave comments!
>>>>
>>>>
>>>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wi
>>>> reframes/admin-portal/v3/3.23%20Edit%20user%20profile.png
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> *Dinali Rosemin Dabarera*
>>>> Software Engineer
>>>> WSO2 Lanka (pvt) Ltd.
>>>> Web: http://wso2.com/
>>>> Email : gdrdabar...@gmail.com
>>>> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
>>>> Mobile: +94770198933 <+94%2077%20019%208933>
>>>>
>>>>
>>>>
>>>>
>>>> <https://lk.linkedin.com/in/dinalidabarera>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>>> twitter: https://twitter.com/godwinamila
>>> <http://wso2.com/signature>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
>> Mobile: +94770198933 <+94%2077%20019%208933>
>>
>>
>>
>>
>> <https://lk.linkedin.com/in/dinalidabarera>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> <https://lk.linkedin.com/in/dinalidabarera>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
twitter: https://twitter.com/godwinamila
<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0 - Admin Portal ] Edit User profile (Update User)

[Godwin Shrimal]

Hi Dinali,

Can you explain what exactly happens when click on Verify button on email
or phone number ? And how do you filter those claims and display those
buttons ?


Thanks
Godwin


On Tue, Mar 14, 2017 at 10:52 AM, Dinali Dabarera  wrote:

> Hi all,
>
> I am implementing Edit User profile in the admin portal as designed in
> [1]. I am using the same account settings profile used in user-portal to
> implement this. I have started implementing UI part first and next moving
> to back-end.
> Since We have to use the same UUF components used in user-portal, I will
> move the UUF components into one module called
> org.wso2.carbon.iam.common-uuf for the m5 release.
>
> Please leave comments!
>
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.23%20Edit%20user%20profile.png
>
> Thanks!
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Godwin Shrimal]

As per my previous example, if authorization fails after first step (Basic
authentication) we should not go for the next step and perform Fido
authentication. right ?

I am not quiet sure about the scope we are going to cover with this
implement, Looks there are valid user cases as above.


Thanks
Godwin


On Wed, Oct 19, 2016 at 9:56 AM, Harsha Thirimanna <hars...@wso2.com> wrote:

> As in sequence diagram, we can't do that, and actually do we need that
> level ?
>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> <http://wso2.com/signature>
>
> On Wed, Oct 19, 2016 at 9:51 AM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> How can we attach authorization handlers in steps level with the current
>> design ?
>>
>> Ex.
>> Step1 : Do basic authentication
>> Step2 : Perform authorization for above authenticated user
>> Step3 : Perform Fido authentication
>>
>> In that case don’t we need to handle it in Step level ? same as how we
>> handle Authenticators  ?
>>
>>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <pulast...@wso2.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> As per the current implementation of the Identity Server's
>>> authentication framework, it does not provide any OOTB authorization
>>> mechanism for the service providers. We are going to provide this
>>> capability to Identity server so that the users can be authorized to
>>> service providers using rules based on user attributes, userstore, time of
>>> the day, etc.
>>>
>>> Following is the proposed sequence for the implementation.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The existing authentication flow is kept as is until the authentication
>>> steps are completed and authentication result decided. At the
>>> AuthenticationRequestHandler (after authentication) if the authentication
>>> is success, we will be calling an AuthorizationHandler with the
>>> authentication context. AuthenticationHandler is responsible for evaluating
>>> the configured policies and responding back whether the user is authorized
>>> or not. If the authorization is not required or handled by the SP
>>> itself, we'll be providing the capability of bypassing the authorization
>>> step per service provider .
>>>
>>> The default implementation of the AuthorizationHandler will be using the
>>> IS's XACML engine for authorization. It will send a XACML request to the
>>> PDP and the request will be evaluated against the policies published to the
>>> PDP. Admins can write XACML policies and publish them to allow/deny the
>>> users logging into SPs based on those policies.
>>>
>>> Also, to retrieve the basic authentication context values (such as SP
>>> Name, authenticated user's username/userstore/tenant) we will provide a
>>> default PIP. In case any complex or derived attributes are needed we can
>>> retrieve them by writing a custom PIP and use them in the policies.
>>>
>>> Please share your thoughts and suggestions.
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: http://blog.pulasthi.org
>>>
>>> <https://wso2.com/signature>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>> twitter: https://twitter.com/godwinamila
>> <http://wso2.com/signature>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
twitter: https://twitter.com/godwinamila
<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Extension point for Password management in user store manager (JDBCUserStoreManager)

[Godwin Shrimal]

Jira [1] created to track this.

[1] https://wso2.org/jira/browse/IDENTITY-4541


Thanks
Godwin


On Tue, Apr 19, 2016 at 9:53 AM, Godwin Shrimal <god...@wso2.com> wrote:

> Hi Prabath,
>
> Yes this is for C4. I am not quit sure how we can achieve this in C5 as
> well.
>
>
> Thanks
> Godwin
>
>
> On Tue, Apr 19, 2016 at 7:50 AM, Prabath Siriwardana <prab...@wso2.com>
> wrote:
>
>> +1
>>
>> I guess this is for the C4 ?
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Mon, Apr 18, 2016 at 4:32 AM, Godwin Shrimal <god...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> There are use case which need to implement some custom password
>>> management scenarios as follows.
>>>
>>> 1. Proprietary hashing and salting are being used.
>>> 2. Integration with third party security modules (Ex. HSM)
>>>
>>> In the current implementation, we can achieve this by writing custom
>>> UserStoreManager,  If we can give an extension point only for password
>>> management in the user store manager we can achieve some practical problems
>>> easily by decoupling the password management.
>>>
>>> WDYT ?
>>>
>>> Thanks
>>> Godwin
>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>>> twitter: https://twitter.com/godwinamila
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +1 650 625 7950
>>
>> http://blog.facilelogin.com
>> http://blog.api-security.org
>>
>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
> twitter: https://twitter.com/godwinamila
>



-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Extension point for Password management in user store manager (JDBCUserStoreManager)

[Godwin Shrimal]

Hi Prabath,

Yes this is for C4. I am not quit sure how we can achieve this in C5 as
well.


Thanks
Godwin


On Tue, Apr 19, 2016 at 7:50 AM, Prabath Siriwardana <prab...@wso2.com>
wrote:

> +1
>
> I guess this is for the C4 ?
>
> Thanks & regards,
> -Prabath
>
> On Mon, Apr 18, 2016 at 4:32 AM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi,
>>
>> There are use case which need to implement some custom password
>> management scenarios as follows.
>>
>> 1. Proprietary hashing and salting are being used.
>> 2. Integration with third party security modules (Ex. HSM)
>>
>> In the current implementation, we can achieve this by writing custom
>> UserStoreManager,  If we can give an extension point only for password
>> management in the user store manager we can achieve some practical problems
>> easily by decoupling the password management.
>>
>> WDYT ?
>>
>> Thanks
>> Godwin
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>> twitter: https://twitter.com/godwinamila
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://blog.facilelogin.com
> http://blog.api-security.org
>



-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Extension point for Password management in user store manager (JDBCUserStoreManager)

[Godwin Shrimal]

Hi,

There are use case which need to implement some custom password management
scenarios as follows.

1. Proprietary hashing and salting are being used.
2. Integration with third party security modules (Ex. HSM)

In the current implementation, we can achieve this by writing custom
UserStoreManager,  If we can give an extension point only for password
management in the user store manager we can achieve some practical problems
easily by decoupling the password management.

WDYT ?

Thanks
Godwin


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.2.0 Alpha Released !!

[Godwin Shrimal]

WSO2 Identity Server 5.2.0 Alpha Released !!Date: 17th March 2016The WSO2
Identity Server team is pleased to announce the release of WSO2 Identity
Server 5.2.0 Alpha. You can download this distribution from
https://github.com/wso2/product-is/releases/tag/v5.2.0-alpha


Following list [1] contains all bug fixes and improvements available with
alpha release. We encourage you to report issues, improvements and feature
requests regarding WSO2 Identity Server through the public WSO2 Identity
Server JIRA 

~ The WSO2 Identity Server Team ~

[1] Release Notes - WSO2 Identity Server - Version 5.2.0-Alpha
Bug

   -

   [IDENTITY-4409 ] - Improve
   gitignore of identity-framework
   -

   [IDENTITY-4410 ] - Remove
   synchronizing the method "hasUserApproved" in "OpenIDConnectUserRPStore"
   class

Improvement

   -

   [IDENTITY-4384 ] -
   IdentityProviderManager should exposed as an osgi service
   -

   [IDENTITY-4390 ] - Adding
   capability to publish Oauth related events

New Feature

   -

   [IDENTITY-3287 ] - API to
   get the number (count) of users

Patch[IDENTITY-4398 ] -
Authorization code can be sent in to get access token multiple times



-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] create tenant via rest api

[Godwin Shrimal]

Hi John,

You can find the relevant  service in [1].

[1]
https://github.com/wso2/carbon-multitenancy/blob/master/components/tenant-mgt/org.wso2.carbon.tenant.mgt/src/main/java/org/wso2/carbon/tenant/mgt/services/TenantMgtAdminService.java


Thanks
Godwin


On Fri, Feb 26, 2016 at 10:10 AM, Rukshan Premathunga 
wrote:

> Hi John,
>
> You can find the code to create tenant at here[1]. But it use the soap
> admin service.
>
> [1]
> https://github.com/ruks/wso2.apim.sample/blob/master/com.rukspot.apimgt.stat/src/main/java/com/rukspot/apimgt/stat/TenantMgt.java
>
>
> Thanks and Regards.
>
> On Fri, Feb 26, 2016 at 9:49 AM, Danushka Fernando 
> wrote:
>
>> There is a soap api. You can use TenantMgtService.
>>
>> Thanks & Regards
>> Danushka Fernando
>> Senior Software Engineer
>> WSO2 inc. http://wso2.com/
>> Mobile : +94716332729
>>
>> On Fri, Feb 26, 2016 at 3:35 AM, John Q  wrote:
>>
>>> Hello everyone,
>>>
>>> I am wondering if there is a rest api for carbon to create tenants?
>>>
>>> I saw that private paas have a rest api for creating tenant, but i only
>>> have installed , wso2is, wso2am and wso2esb and don't use the private paas.
>>>
>>> If there is such api please where can i find it?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Evaluating a Yaml parser for C5

[Godwin Shrimal]

Hi Botheju,

It looks SnakeYaml has an active community according to [1]

[1]
http://adamnengland.com/2012/04/26/java-yaml-shootout-snakeyaml-vs-yamlbeans/

Thanks
Godwin

On Mon, Nov 23, 2015 at 12:29 PM, Dinusha Boteju  wrote:

> Hi all,
>
> I'm in the  course of integrating a YAML based configuration into the C5
> kernel. For this, I have come across few yaml parsers and opted 2.
> Following is a summary of both of these parsers;
>
>- YamlBeans
>- License : New BSD
>   - Size of the distribution (version 1.1.0): 153.6kb
>   - Url: http://yamlbeans.sourceforge.net/
>   
>   - marshalling and unmarshalling supported
>
>
>- SnakeYAML
>   - License: Apache License, Version 2.0
>   - Size of the distribution (version 1.16): 269.6kb
>   - Url: https://bitbucket.org/asomov/snakeyaml
>   - marshalling and unmarshalling supported
>
> Appreciate your thoughts on which one to use from the aforementioned
> libraries. If any other good parser are available please fill in.
>
> Thanks
> --
> *Dinusha Boteju*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
> email: dinus...@wso2.com 
> phone:(+94) 776640275 <%28%2B94%29%2039736>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture