Re: [Dev] Using default user attributes provided by Active Directory for SCIM operations

[Johann Nallathamby]

Had an offline discussion with Gayashan and understood why we had to
configure the immutable attributes per user store since I was a
little confused. The reason is that in order to read those immutable
attributes we still have to configure the mappings to them. However, we
should avoid writing to them. Though there is a property called "read-only"
it is configurable only at a claim level; we can't configure that at a user
store level. We need it to be at a user store level since we can have
multiple types of users stores in a deployment.

Thanks & Regards,
Johann.

On Wed, Mar 25, 2020 at 10:25 AM Gayashan Bombuwala 
wrote:

> Hi Johann,
>
> We used to map[1] SCIM core attributes/claims like lastModifiedTIme
> createdTIme, scimId to some random attributes available from Active
> Directory such as homePostalAddress, streetAddress, pager, etc.
> However, Active Directory also has user attributes which are maintained by
> Active Directory itself such as whenChanged, whenCreated, objectGuid.
> Hence, we can make use of these Active Directory maintained attributes
> when mapping SCIM attributes/claims to AD attributes, instead of randomly
> mapping to some available attribute.
> Ex: the whenChanged attribute will be automatically updated by AD
> whenever we change a user attribute.
> See the following example mapping.
>
> CLAIM URI
> MAPPED ATTRIBUTE
> urn:scim:schemas:core:2.0:id objectGuid
> urn:scim:schemas:core:2.0:meta.created whenCreated
> urn:scim:schemas:core:2.0:meta.lastModified whenChanged
>
>
> However,* these Active Directory maintained user attributes are also
> immutable.*
> Hence, *we should make sure that we don't update the values of those
> attributes when performing SCIM operations *such when creating or
> updating a user.
> That's why we have introduced the "immutable attributes" property[2], so
> that we can keep track of which user store attributes should not be updated
> when performing SCIM operations.
>
> [1]
> https://docs.wso2.com/display/IS500/Provisioning+Users+to+Active+Directory+User+Store+Using+SCIM
> [2]
> https://is.docs.wso2.com/en/5.10.0/setup/configuring-a-read-write-active-directory-user-store/
>
> Thanks,
> Gayashan
>
> On Wed, Mar 25, 2020 at 9:57 AM Johann Nallathamby 
> wrote:
>
>> Hi Gayanshan,
>>
>> What is the purpose of defining the immutable attributes of Active
>> Directory in the "Immutable Attributes" property? How is this property used?
>>
>> Regards,
>> Johann.
>>
>> On Sat, Feb 1, 2020 at 11:04 PM Gayashan Bombuwala 
>> wrote:
>>
>>> Hi Johann, Darshana,
>>>
>>> This was implemented in the product in [1].
>>> In this implementation, we introduced two hooks for processing user
>>> attributes in the AbstarctUserStoreManager level.
>>>
>>> 1. To handle the processing of the user attributes after reading from
>>> the user store [2].
>>> 2. To handle the processing of the user attributes before writing to the
>>> user store [3].
>>>
>>> A unique ID variant [4], [5] of each of the above methods  [2], [3] was
>>> introduced as well in order to comply with the new unique ID user store
>>> implementations.
>>>
>>> The behaviour of these hooks can be decided in a specific user store
>>> level.
>>> As per the implementation [1], we have implemented the behaviour of
>>> these hooks in UniqueIDActiveDirecotryUserStoreManager and
>>> ActiveDirectoryUserStoreManager [6], [7].
>>>
>>> We have introduced two new user store properties to support the
>>> implementation.
>>> 1. Immutable Attributes
>>> 2. Timestamp Attributes
>>>
>>> Immutable Attributes property is used to identify the user store
>>> maintained immutable attributes in Active Directory such as objectGuid,
>>> whenChanged, whenCreated.
>>> Timestamp Attributes property is used to identify the attributes in
>>> Active Directory which belong to the "Generalized Time" data type and need
>>> to be converted to the standard date format before used within WSO2 iS
>>> (e.g. whenChanged, whenCreated).
>>> The usage of these two user store properties is documented in [8].
>>>
>>> [1] https://github.com/wso2/carbon-kernel/pull/2514
>>> [2]
>>> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L7488
>>> [3]
>>> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc41

Re: [Dev] Using default user attributes provided by Active Directory for SCIM operations

[Johann Nallathamby]

Hi Gayanshan,

What is the purpose of defining the immutable attributes of Active
Directory in the "Immutable Attributes" property? How is this property used?

Regards,
Johann.

On Sat, Feb 1, 2020 at 11:04 PM Gayashan Bombuwala 
wrote:

> Hi Johann, Darshana,
>
> This was implemented in the product in [1].
> In this implementation, we introduced two hooks for processing user
> attributes in the AbstarctUserStoreManager level.
>
> 1. To handle the processing of the user attributes after reading from the
> user store [2].
> 2. To handle the processing of the user attributes before writing to the
> user store [3].
>
> A unique ID variant [4], [5] of each of the above methods  [2], [3] was
> introduced as well in order to comply with the new unique ID user store
> implementations.
>
> The behaviour of these hooks can be decided in a specific user store level.
> As per the implementation [1], we have implemented the behaviour of these
> hooks in UniqueIDActiveDirecotryUserStoreManager and
> ActiveDirectoryUserStoreManager [6], [7].
>
> We have introduced two new user store properties to support the
> implementation.
> 1. Immutable Attributes
> 2. Timestamp Attributes
>
> Immutable Attributes property is used to identify the user store
> maintained immutable attributes in Active Directory such as objectGuid,
> whenChanged, whenCreated.
> Timestamp Attributes property is used to identify the attributes in Active
> Directory which belong to the "Generalized Time" data type and need to be
> converted to the standard date format before used within WSO2 iS (e.g.
> whenChanged, whenCreated).
> The usage of these two user store properties is documented in [8].
>
> [1] https://github.com/wso2/carbon-kernel/pull/2514
> [2]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L7488
> [3]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L7500
> [4]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L7512
> [5]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L7524
> [6]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/ldap/UniqueIDActiveDirectoryUserStoreManager.java#L912
> [7]
> https://github.com/wso2/carbon-kernel/blob/b5048093ea69a24a24a71e99e62e4b1dfc412796/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/ldap/UniqueIDActiveDirectoryUserStoreManager.java#L935
> [8]
> https://is.docs.wso2.com/en/latest/setup/configuring-a-read-write-active-directory-user-store/#properties-used-in-read-write-active-directory-userstore-manager
>
> Best Regards,
> Gayashan
>
> On Sat, Feb 1, 2020 at 9:13 PM Darshana Gunawardana 
> wrote:
>
>> Hi Gayashan,
>>
>> Is this implemented in the product now? If so can you share details on
>> the final approach you took.
>>
>> Thanks,
>>
>> On Thu, Jan 2, 2020 at 9:37 AM Johann Nallathamby 
>> wrote:
>>
>>> Hi Gayashan,
>>>
>>> On Tue, Dec 3, 2019 at 6:54 PM Gayashan Bombuwala 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently when managing users in Active Directory user store with SCIM,
>>>> we have mapped the SCIM core attributes to different attributes[1, 2]
>>>> supported by SCIM.
>>>>
>>>> e.g. urn:ietf:params:scim:schemas:core:2.0:id (SCIM attribute)->
>>>> http://wso2.org/claims/userid (local claim) -> homePostalAddress
>>>> (Active Directory attribute)
>>>>
>>>> However, there are a set of attributes maintained by Active Directory
>>>> which we can use to map some of core SCIM attributes. We have considered
>>>> the following attributes for the moment.
>>>>
>>>>1. objectGuid (AD maintained attribute) ->
>>>>urn:ietf:params:scim:schemas:core:2.0:id (SCIM attribute)
>>>>2. whenCreated (AD maintained attribute) ->
>>>>urn:ietf:params:scim:schemas:core:2.0:created (SCIM attribute)
>>>>3. whenModified (AD maintained attribute)- ->
>>>>urn:i

Re: [Dev] Using default user attributes provided by Active Directory for SCIM operations

[Johann Nallathamby]

Hi Gayashan,

On Tue, Dec 3, 2019 at 6:54 PM Gayashan Bombuwala 
wrote:

> Hi all,
>
> Currently when managing users in Active Directory user store with SCIM, we
> have mapped the SCIM core attributes to different attributes[1, 2]
> supported by SCIM.
>
> e.g. urn:ietf:params:scim:schemas:core:2.0:id (SCIM attribute)->
> http://wso2.org/claims/userid (local claim) -> homePostalAddress (Active
> Directory attribute)
>
> However, there are a set of attributes maintained by Active Directory
> which we can use to map some of core SCIM attributes. We have considered
> the following attributes for the moment.
>
>1. objectGuid (AD maintained attribute) ->
>urn:ietf:params:scim:schemas:core:2.0:id (SCIM attribute)
>2. whenCreated (AD maintained attribute) ->
>urn:ietf:params:scim:schemas:core:2.0:created (SCIM attribute)
>3. whenModified (AD maintained attribute)- ->
>urn:ietf:params:scim:schemas:core:2.0:lastModified (SCIM attribute)
>
> We need to handle the mapping of these attributes in two scenarios.
>
>1. When reading values from the user store.
>2. When writing values to the user store.
>
>
> When reading from the user store we can introduce a hook to handle the
> mapping of these special attributes. We can implement the hook in
> AbstractUserStoreManager since local claim to user store property mapping
> is done in that[3] level. When the attributes are mapped we may need to do
> a conversion between data types for some attributes (e.g. objectGuid
> property is stored in AD as an octetSting [3]). This hook will be a method
> with the following signature.
>
> protected void processRetrievedSpecialClaims (Map
> specialClaims)
>

Why do we need to have "special" in the method name? Shouldn't all
attribute processing go through this method? Why limit this to certain
claims? We don't need to decide beforehand what claims have to go through
this method. If someone wants to handle certain claim in special way later
on they can extend this particular method.

Regards,
Johann.


>
> However, when writing values to the user store, we need to handle the
> special claims in the user store level [5]. We can do data type conversion
> for special claim values here as well if required.
> We will introduce an abstract hook in the AbstractUserStoreManager level
> but will provide separate implementations in the user store level. This
> hook will be a method with the following signature.
>
> protected void processSpecialClaimsForUpdating (Map
> specialClaims)
>
> Note that the above mentioned new  behaviour will only be executed if a
> specific user store property is enabled.
>  Please let us know if you have any concerns regarding this approach.
>
> Best Regards,
> Gayashan
>
> [1]
> https://docs.wso2.com/display/IS570/Configuring+Active+Directory+User+Stores+for+SCIM+2.0+based+Inbound+Provisioning
> [2] http://www.kouti.com/tables/userattributes.htm
> [3] https://docs.microsoft.com/en-us/windows/win32/adschema/s-string-octet
> [4]
> https://github.com/wso2/carbon-kernel/blob/eb6660d83a4ee29214924c5b7592fa30e259d7b5/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L5388
> [5]
> https://github.com/wso2/carbon-kernel/blob/eb6660d83a4ee29214924c5b7592fa30e259d7b5/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/ldap/ActiveDirectoryUserStoreManager.java#L616
>
> --
> *Gayashan Bombuwala*
> Software Engineer | WSO2
>
> Email: gayash...@wso2.com
> Phone: +94770548334
>
> [image: https://wso2.com/signature] 
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Passing service provider object to the postDeleteHandler of the ApplicationMgtListener

[Johann Nallathamby]

What if we ship an implementation of the new interceptor method that
iteratively calls the old interceptor method from the registered
interceptors? This way the changes to the core will be done and deprecated
old method is only invoked from new interceptor; easier to disable it in a
running system or even remove it in next version.


On Mon, Nov 4, 2019 at 7:43 PM Farasath Ahamed  wrote:

>
>
> On Fri, Nov 1, 2019 at 4:38 PM Gayashan Bombuwala 
> wrote:
>
>> Hi Johann,
>>
>> Both the new handler and the old handler will be called at the end[1] of
>> deleteServiceProvider() execution.
>> By the time that postDeleteHandler gets executed, the relevant Service
>> Provider object will been already removed. Hence, we can't read the Service
>> Provider object based on the name inside the postDeltedHandler.
>> We have also deprecated[2] the old postDeleteHandler.
>>
>
> Instead of calling both old and new methods of the listener. Can't we add
> a default implementation at the interface level like below for the new
> method,
>
> default boolean doPostDeleteApplication(ServiceProvider serviceProvider,
> String tenantDomain, String userName)
> throws IdentityApplicationManagementException {
> return doPostDeleteApplication(serviceProvider.getName(),
> tenantDomain, userName);
> }
>
> and call only the new method doPostDeleteApplication(ServiceProvider
> serviceProvider, String tenantDomain, String userName) at the OSGi service
> level.
>
> This way we consume the new API only and any listener written implementing
> the deprecated method will also work without an issue.
>
>
>> [1]
>> https://github.com/wso2/carbon-identity-framework/blob/07c9b78564dbd4fd652ae323d3f3ef264cf5/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/ApplicationManagementServiceImpl.java#L746
>> [2]
>> https://github.com/wso2/carbon-identity-framework/blob/07c9b78564dbd4fd652ae323d3f3ef264cf5/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L121
>>
>> Regards,
>> Gayashan.
>>
>> On Fri, Nov 1, 2019 at 3:37 PM Johann Nallathamby 
>> wrote:
>>
>>> Hi Gayashan,
>>>
>>> Though you introduce the method in the API, who calls the method? Now
>>> that there are two methods is the ApplicationMgtService going to call both
>>> the methods? Can't we read the Service Provider object based on the name
>>> rather than introducing a new method for it?
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Fri, Oct 25, 2019 at 4:45 PM Gayashan Bombuwala 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently implementation of the postDeleteHandler[1] of
>>>> ApplicationMgtListener only accepts the name of the service provider as a
>>>> parameter. However the postCreateHandler[2] and postUpdateHandler[3] of the
>>>> ApplicationMgtListener accepts the relevant Service Provider object as a
>>>> parameter rather than just the service provider name.We will be introducing
>>>> a new overloaded postDeleteHandler to the ApplicationMgtListener interface
>>>> where the relevant Service Provider object get passed to the handler
>>>> similar to the postCreateHandler[2] and postUpdateHandler[3] as the
>>>> relevant Service Provider information is required for logging purposes.
>>>>
>>>> [1]
>>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L117
>>>>
>>>> [2]
>>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L69
>>>>
>>>> [3]
>>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L93
>>>>
>>>> Thanks,
>>>> --
>>>> *Gayashan Bombuwala*
>>>> Software Engineer | WSO2
>>>>
>>>> Email: gayash...@wso2.com
>>>> Phone: +94770548334
>&

Re: [Dev] Passing service provider object to the postDeleteHandler of the ApplicationMgtListener

[Johann Nallathamby]

Hi Gayashan,

Though you introduce the method in the API, who calls the method? Now that
there are two methods is the ApplicationMgtService going to call both the
methods? Can't we read the Service Provider object based on the name rather
than introducing a new method for it?

Regards,
Johann.

On Fri, Oct 25, 2019 at 4:45 PM Gayashan Bombuwala 
wrote:

> Hi all,
>
> Currently implementation of the postDeleteHandler[1] of
> ApplicationMgtListener only accepts the name of the service provider as a
> parameter. However the postCreateHandler[2] and postUpdateHandler[3] of the
> ApplicationMgtListener accepts the relevant Service Provider object as a
> parameter rather than just the service provider name.We will be introducing
> a new overloaded postDeleteHandler to the ApplicationMgtListener interface
> where the relevant Service Provider object get passed to the handler
> similar to the postCreateHandler[2] and postUpdateHandler[3] as the
> relevant Service Provider information is required for logging purposes.
>
> [1]
> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L117
>
> [2]
> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L69
>
> [3]
> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L93
>
> Thanks,
> --
> *Gayashan Bombuwala*
> Software Engineer | WSO2
>
> Email: gayash...@wso2.com
> Phone: +94770548334
>
> [image: https://wso2.com/signature] 
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Binding access token to the browser for new IAM Portal Applications

[Johann Nallathamby]

Hi Darshana,

On Sat, Sep 28, 2019 at 8:29 PM Darshana Gunawardana 
wrote:

> Hi Johann,
>
> On Sat, Sep 21, 2019 at 10:43 AM Johann Nallathamby 
> wrote:
>
>> Hi Thanuja,
>>
>> Did we consider sending the access token itself as a secure, http-only
>> cookie to the browser instead of binding it to a separate cookie? This will
>> also simplify the development on the client side, in case someone wants to
>> build their own SPA.
>>
>
> Here which domain you assumed that the cookie will be set to?
>

I meant to the IS server domain which is the domain where the APIs are
hosted.


>
> Assuming it the client's domain, there are two limitations.
>
>1. Setting the token as a cookie is an additional task that client had
>to do since OP (in this case IS) cannot set cookies for some external
>client domain.
>2. Having the token stored in http-only cookie block accessing it's
>from client-side scripts, which is a main blocker for SPAs.
>
>
Not client domain.


>
> Assuming it the server-side domain and assuming you want to automatically
> handle authorization for the API based on the access token that already
> present in the cookie, there are two concerns,
>
>1. This will open up CSRF vulnerability as any malicious client
>running on the same browser can also access APIs successfully.
>
> Yes, your approach will prevent CSRF as well. +1.

>
>1. If the API gateway handling authorization in back-channel mode,
>   1. The cookie has to set to the API gateway's domain
>   2. API gateway has to do an additional non-standard way of handing
>   this cookie and attach it to the authorization header.
>
> Yes, this is a possibility. But I wasn't proposing it in this case.

Thanks for the clarification.

Regards,
Johann.


>
> Thanks,
>
>>
>> Regards,
>> Johann.
>>
>> On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> With the introduction of new IAM portal applications, there is a
>>> requirement to provide additional security measures to secure these SPAs.
>>> We have already implemented the OAuth2 authorization code flow(public
>>> client) with PKCE for these applications and with this feature, it will be
>>> possible to bind the access token to the browser instance. So, an
>>> additional security measure will be enforced as the combination of the
>>> access token and browser token(cookie) validated while accessing the IS
>>> APIs.
>>> Support for configuring this option using OAuth2 application
>>> configuration and browser token persistence will be added as well.
>>>
>>> Updated request/response flow is as follows,
>>> [image: Blank Diagram (1).png]
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Technical Lead
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891
>>>
>>
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859*Lean . Enterprise . Middleware
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Binding access token to the browser for new IAM Portal Applications

[Johann Nallathamby]

Hi Prakhash,

On Mon, Sep 23, 2019 at 4:34 PM Prakhash Sivakumar 
wrote:

> Hi Johann,
>
> On Sat, Sep 21, 2019 at 7:13 AM Johann Nallathamby 
> wrote:
>
>> Hi Thanuja,
>>
>> Did we consider sending the access token itself as a secure, http-only
>> cookie to the browser instead of binding it to a separate cookie? This will
>> also simplify the development on the client side, in case someone wants to
>> build their own SPA.
>>
> In this case if the access token is compromised the attacker can simply
> inject the token to browser and perform the attack. So I don't see the
> above option is providing an additional security that we are trying to
> provide here.
>

Maybe you misunderstood my suggestion. What I meant was to have the access
token itself stored in a secure http-only cookie from IS backend. So it
cannot be compromised by XSS or something like that.

Regards,
Johann.


> So IMO we should use such additional browser token as a cookie with
> secure, http-only headers added. Maybe we can provide this as a
> configurable feature if someone wants to build their own SPA and they wants
> to omit this browser token.
>
> Thanks
>
>>
>> Regards,
>> Johann.
>>
>> On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> With the introduction of new IAM portal applications, there is a
>>> requirement to provide additional security measures to secure these SPAs.
>>> We have already implemented the OAuth2 authorization code flow(public
>>> client) with PKCE for these applications and with this feature, it will be
>>> possible to bind the access token to the browser instance. So, an
>>> additional security measure will be enforced as the combination of the
>>> access token and browser token(cookie) validated while accessing the IS
>>> APIs.
>>> Support for configuring this option using OAuth2 application
>>> configuration and browser token persistence will be added as well.
>>>
>>> Updated request/response flow is as follows,
>>> [image: Blank Diagram (1).png]
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Technical Lead
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891
>>>
>>
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Prakhash Sivakumar | Senior Software Engineer | WSO2 Inc*
> *+94771510080 | prakh...@wso2.com 
> | https://medium.com/@PrakhashS <https://medium.com/@PrakhashS>*
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Binding access token to the browser for new IAM Portal Applications

[Johann Nallathamby]

Hi Thanuja,

Did we consider sending the access token itself as a secure, http-only
cookie to the browser instead of binding it to a separate cookie? This will
also simplify the development on the client side, in case someone wants to
build their own SPA.

Regards,
Johann.

On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe  wrote:

> Hi All,
>
> With the introduction of new IAM portal applications, there is a
> requirement to provide additional security measures to secure these SPAs.
> We have already implemented the OAuth2 authorization code flow(public
> client) with PKCE for these applications and with this feature, it will be
> possible to bind the access token to the browser instance. So, an
> additional security measure will be enforced as the combination of the
> access token and browser token(cookie) validated while accessing the IS
> APIs.
> Support for configuring this option using OAuth2 application configuration
> and browser token persistence will be added as well.
>
> Updated request/response flow is as follows,
> [image: Blank Diagram (1).png]
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Technical Lead
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] JIRA Not Resolved?

[Johann Nallathamby]

As far as I know we do support internationalization of
/accountrecoveryendpoint [1]. However, seems the JIRA is still open for
this [2]. At the same time I couldn't find a JIRA for internationalization
of /dashboard.

[1] https://github.com/wso2/carbon-identity-framework/pull/1566
[2] https://github.com/wso2/product-is/issues/5657

Thanks & Regards,
Johann.

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture][IAM] Moving File Based Artifacts to Artifact Store

[Johann Nallathamby]

 flow
designer output can definitely be treated as artifacts, which like you said
define authentication/authorization flows

However, if you look at user stores, IdPs and SPs , one could think of them
as abstract entities in the flow, but their concrete form will be decided
based on configuration that we do. This is analogous to Siddhi queries
(artifacts) and output event adaptors (configuration). This is the model I
ideally would like to have, which is a mix of the two.

One of the important tenets about artifacts is that, the artifact must not
change from environment to environment, but the configurations can, and
therefore have to be externalized. Do SPs, IdPs and user stores qualify in
this sense?


> c) A change in a particular "User Store" usually affect the
> "Authentication" decisions done via SP config. Hence they have tight
> coupling.
>

Hmm.. can you give an example. I won't expect such a thing to exist, and if
it does I would think of it as a design problem. SP shouldn't even know
what the user store type is or who are the users who can authenticate to
it. All it should care about is whether the IdP can identify a valid user
and communicate it to the service provider.


> d) All "User Store", "SP", "IdP", etc, need to be taken as one unit, when
> we consider environment to environment promotion of these configs.
> (Dev->QA->staging->Prod)
>

Agreed. And that can be done with file based representation and
import/export APIs.


> Hence IMHO, treating "User Store" as the file-based artifact was a right
> decision, when our products have been designed for deployment on bear-metal
> or VM. However moving forward to container, and cloud nativeness, posses
> the challenge on sharing these artifacts.
>

This is where database persistence will help I think.


>
>

> Also, considering the CI/CD pipelines, the governance aspect of changing
> the configurations, etc, these type of configs need to be considered as
> artifacts. We might need to version control these artifacts in future and
> may need to push and pull them from VCS systems.
>

Have we had a significant percentage of IAM customers who have asked for
this level of governance in the past? I can't remember any from the top of
my head. Or else are we consciously shifting our outlook based on what we
believe is the next phase of the product?


>
> What we need to do is to have a delegation pattern implemented for all
> current file based (and registry based artifacts), where we can switch the
> repository from file based one to different system. DB based repository
> would be the first such(simple) implementation. We may need to implement
> Git based repository when we properly support cloud use cases for example.
> We can abstract the storage system, and retain all the parsing and
> generation logic unchanged for artifacts. it would be a minimal change and
> most versatile way to extend IMO.
>
> We would need to implement property or "environment variable" binding
> logic, to get proper support for environment to environment promotion of
> artifacts. yet, it can be done with a separate effort than this IMO.
>

How much difference is there between what you are explaining above as
environment specific properties and what we have today as SP, IdP or User
Store configurations?
Do you think we might have mixed up configurations and what qualify as
artifacts originally and that is the problem? Do you think we can cleanly
separate out the environment specific properties as SP, IdP and user stores
and still have configurations along with artifacts?

Sorry if I am asking too many questions, but just want to be able to
convince myself that we are doing the right thing here once and for all :)

Thanks & Regards,
Johann.


>
> Hence +1 to treat
>
>- Persist data as a blob (marshalled to text form)
>- In a separate table structure.
>
> Cheers,
> Ruwan A
>
>
> On Tue, Jun 4, 2019 at 3:50 PM Johann Nallathamby  wrote:
>
>> +1 to get rid of the artifacts for user stores. I think this was a wrong
>> decision we made early on.
>>
>> On Tue, Jun 4, 2019 at 1:19 PM Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> *Problem *
>>> Currently, some artifacts like userstores , tenants' data, etc are
>>> stored in the file system (not in the database). So when using a clustered
>>> setup those artifacts should be shared among all the nodes by using one of
>>> the following file sharing mechanisms.
>>>
>>>- Dep Sync
>>>- rSync
>>>- Shared File System
>>>
>>>
>>> *Solution *
>>> In order to avoid a shared file system and to red

Re: [Dev] [IS] Rest API for scopes

[Johann Nallathamby]

Hi Janak,

Thanks for brining this up. I also noticed this recently when I was doing
some demo for a customer and was planning to send a mail on this.

When we did the OIDC scopes management feature we should have addressed the
OAuth2 scopes management as well. I searched back to see if there has been
any discussion on this on architecture and I found [1]. However, the thread
hasn't been updated with the progress of the development and screenshots :(.

We can't have two separate scope management features in the product. There
is only one concept of scopes and it is a usage of scope that is there in
OIDC. So definitely +1 to use the same set of APIs to expose this
externally.

Isn't this the purpose of Resource Set Registration profile? Aren't those
APIs same as one of the above APIs? Else do we have 3 separate APIs now? We
can only have one API.

[1] "Moving oidc scope-claim mapping from registry to db" in
architect...@wso2.org

Thanks & Regards,
Johann.

On Tue, Jul 2, 2019 at 2:20 PM Janak Amarasena  wrote:

> Hi All,
>
> We have two implementations related to scopes in the IS, one for OAuth2
> scopes (for oauth2 scopes and scope bindings(role, permission etc)) and the
> other for OIDC scopes (for scope claim mappings). The data is also stored
> separately.
> For the OAuth2 scope management, we already have a REST API[1] and with
> the OAuthAdminService Soap API, we manage the OIDC scopes.
> When designing the REST API to include OIDC scopes management there are
> two ways this can be done.
>
>1. Have a seperate API for OIDC scope managment.
>2. Include the OIDC scope management and OAuth scope management in the
>same REST API and treat them both as a single resource when exposing it to
>the outside and manage them separately internally.
>
> [1] -
> https://docs.wso2.com/display/IS580/apidocs/OAuth2-scope-endpoint/index.html
>
> Your thoughts on this are much appreciated.
>
> Thank you,
> Best Regards,
>
> Janak
>
> --
> *Janak Amarasena* | Software Engineer | WSO2 Inc.
> (m) +9464144 | (w) +94112145345 | (e) ja...@wso2.com
>
>
> 
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture][IAM] Moving File Based Artifacts to Artifact Store

[Johann Nallathamby]

Ignore the question Isura, I think Ruwan's reply contains the answer.

Regards,
Johann.

On Thu, Jul 4, 2019 at 8:48 AM Johann Nallathamby  wrote:

> Hi Isura,
>
> On Fri, Jun 7, 2019 at 9:16 AM Isura Karunaratne  wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 9:34 AM Ruwan Abeykoon  wrote:
>>
>>> Hi All,
>>> The "User Store" configuration can be considered as a deployment
>>> artifact if we look at the following aspects.
>>>
>>> a) "Secondary User Stores" are added, removed and updated per tenant
>>> basis. (Same as SP, and IdP configs)
>>> b) "User Store", "IdP" and "SP", XACML policies, etc behaves as a
>>> collection of business rules, defining the authentication and authorization
>>> flows per the tenant.
>>> c) A change in a particular "User Store" usually affect the
>>> "Authentication" decisions done via SP config. Hence they have tight
>>> coupling.
>>> d) All "User Store", "SP", "IdP", etc, need to be taken as one unit,
>>> when we consider environment to environment promotion of these configs.
>>> (Dev->QA->staging->Prod)
>>>
>>> Hence IMHO, treating "User Store" as the file-based artifact was a right
>>> decision, when our products have been designed for deployment on bear-metal
>>> or VM. However moving forward to container, and cloud nativeness, posses
>>> the challenge on sharing these artifacts.
>>>
>>> Also, considering the CI/CD pipelines, the governance aspect of changing
>>> the configurations, etc, these type of configs need to be considered as
>>> artifacts. We might need to version control these artifacts in future and
>>> may need to push and pull them from VCS systems.
>>>
>>> What we need to do is to have a delegation pattern implemented for all
>>> current file based (and registry based artifacts), where we can switch the
>>> repository from file based one to different system. DB based repository
>>> would be the first such(simple) implementation. We may need to implement
>>> Git based repository when we properly support cloud use cases for example.
>>> We can abstract the storage system, and retain all the parsing and
>>> generation logic unchanged for artifacts. it would be a minimal change and
>>> most versatile way to extend IMO.
>>>
>>> We would need to implement property or "environment variable" binding
>>> logic, to get proper support for environment to environment promotion of
>>> artifacts. yet, it can be done with a separate effort than this IMO.
>>>
>>> Hence +1 to treat
>>>
>>>- Persist data as a blob (marshalled to text form)
>>>- In a separate table structure.
>>>
>>> Cheers,
>>> Ruwan A
>>>
>>>
>>> On Tue, Jun 4, 2019 at 3:50 PM Johann Nallathamby 
>>> wrote:
>>>
>>>> +1 to get rid of the artifacts for user stores. I think this was a
>>>> wrong decision we made early on.
>>>>
>>>> On Tue, Jun 4, 2019 at 1:19 PM Hasanthi Purnima Dissanayake <
>>>> hasan...@wso2.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> *Problem *
>>>>> Currently, some artifacts like userstores , tenants' data, etc are
>>>>> stored in the file system (not in the database). So when using a clustered
>>>>> setup those artifacts should be shared among all the nodes by using one of
>>>>> the following file sharing mechanisms.
>>>>>
>>>>>- Dep Sync
>>>>>- rSync
>>>>>- Shared File System
>>>>>
>>>>>
>>>>> *Solution *
>>>>> In order to avoid a shared file system and to reduce the deployment
>>>>> and maintenance overhead, those artifacts ca be persisted in the database
>>>>> itself.
>>>>>
>>>>> *Approach*
>>>>> After discussing with @Ruwan Abeykoon   and @Isura
>>>>> Karunaratne  we have two options to persist above
>>>>> discussed artifact details.
>>>>>
>>>>>- In the configuration store which is already implemented as
>>>>>discussed in [1][2].
>>>>>- In a separate table structure.
>>>>>
>>>>> If we are to go with option 01, then we need to consider the artifacts
&

Re: [Dev] [Architecture][IAM] Moving File Based Artifacts to Artifact Store

[Johann Nallathamby]

Hi Isura,

On Fri, Jun 7, 2019 at 9:16 AM Isura Karunaratne  wrote:

>
>
> On Wed, Jun 5, 2019 at 9:34 AM Ruwan Abeykoon  wrote:
>
>> Hi All,
>> The "User Store" configuration can be considered as a deployment artifact
>> if we look at the following aspects.
>>
>> a) "Secondary User Stores" are added, removed and updated per tenant
>> basis. (Same as SP, and IdP configs)
>> b) "User Store", "IdP" and "SP", XACML policies, etc behaves as a
>> collection of business rules, defining the authentication and authorization
>> flows per the tenant.
>> c) A change in a particular "User Store" usually affect the
>> "Authentication" decisions done via SP config. Hence they have tight
>> coupling.
>> d) All "User Store", "SP", "IdP", etc, need to be taken as one unit, when
>> we consider environment to environment promotion of these configs.
>> (Dev->QA->staging->Prod)
>>
>> Hence IMHO, treating "User Store" as the file-based artifact was a right
>> decision, when our products have been designed for deployment on bear-metal
>> or VM. However moving forward to container, and cloud nativeness, posses
>> the challenge on sharing these artifacts.
>>
>> Also, considering the CI/CD pipelines, the governance aspect of changing
>> the configurations, etc, these type of configs need to be considered as
>> artifacts. We might need to version control these artifacts in future and
>> may need to push and pull them from VCS systems.
>>
>> What we need to do is to have a delegation pattern implemented for all
>> current file based (and registry based artifacts), where we can switch the
>> repository from file based one to different system. DB based repository
>> would be the first such(simple) implementation. We may need to implement
>> Git based repository when we properly support cloud use cases for example.
>> We can abstract the storage system, and retain all the parsing and
>> generation logic unchanged for artifacts. it would be a minimal change and
>> most versatile way to extend IMO.
>>
>> We would need to implement property or "environment variable" binding
>> logic, to get proper support for environment to environment promotion of
>> artifacts. yet, it can be done with a separate effort than this IMO.
>>
>> Hence +1 to treat
>>
>>- Persist data as a blob (marshalled to text form)
>>- In a separate table structure.
>>
>> Cheers,
>> Ruwan A
>>
>>
>> On Tue, Jun 4, 2019 at 3:50 PM Johann Nallathamby 
>> wrote:
>>
>>> +1 to get rid of the artifacts for user stores. I think this was a wrong
>>> decision we made early on.
>>>
>>> On Tue, Jun 4, 2019 at 1:19 PM Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> *Problem *
>>>> Currently, some artifacts like userstores , tenants' data, etc are
>>>> stored in the file system (not in the database). So when using a clustered
>>>> setup those artifacts should be shared among all the nodes by using one of
>>>> the following file sharing mechanisms.
>>>>
>>>>- Dep Sync
>>>>- rSync
>>>>- Shared File System
>>>>
>>>>
>>>> *Solution *
>>>> In order to avoid a shared file system and to reduce the deployment and
>>>> maintenance overhead, those artifacts ca be persisted in the database
>>>> itself.
>>>>
>>>> *Approach*
>>>> After discussing with @Ruwan Abeykoon   and @Isura
>>>> Karunaratne  we have two options to persist above
>>>> discussed artifact details.
>>>>
>>>>- In the configuration store which is already implemented as
>>>>discussed in [1][2].
>>>>- In a separate table structure.
>>>>
>>>> If we are to go with option 01, then we need to consider the artifacts
>>>> as configurations and persist in the existing schema.
>>>>
>>> The advantage of using this is we can re-use the existing implementation
>>>> including the database schema and existing rest APIs and functionalities
>>>> (pagination, searching, etc) .
>>>>
>>>
>>>
>>
> Hi all,
>
>
>> The drawback is the conceptual difference between an artifact and
>>>> configuration.
>>>>
>>>
>>&g

[Dev] [IAM] Why IS SSO samples have a dependency to ClaimManagerProxy?

[Johann Nallathamby]

Folks,

Why does all the IS SSO samples in [1], have a dependency on
ClaimManagerProxy?
1. This is a fundamental mistake because a sample using standard federation
protocols should be not coupled to the Identity Server. We should be able
to run it against any other IdP to demonstrate compatibility.
2. Sample startup fails unless IS is already started since it invokes some
web service in IS.

Though I also noticed this earlier, a customer in fact raised this question
to me which got me thinking the impact it could have on first time users.
In some cases users do try to go through code for inspiration. So it is
better to avoid such coupling. Shall we please fix this?

[1] https://github.com/wso2/samples-is/blob/master/sso-samples/

Thanks & Regards,
Johann.

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Why "Analytics Engine" and "Consent Information Controller" configurations are under "Resident Identity Provider"?

[Johann Nallathamby]

Hi Folks,

I just noticed that IS analytics engine configuration is under resident IdP
configurations. How do we consider an analytics engine configuration as an
Identity Provider configuration?

Resident IdP configurations are ideally any "configurations" that impact
runtime interactions with service providers registered in IS, such as
identity management services, authentication services, authorization
services and attribute sharing services (not exhaustive).

Analytics engine configuration is a server configuration which is similar
to "Workflow Engine Profiles" configuration, which is under "Configure" tab
already. Shouldn't analytics engine configuration also come under
"Configure" tab?

With respect to "Consent Information Controller" configurations, do the
details that we configure have any relevance to the service providers? Are
those values that we configure, exposed through an API for the service
providers to consume? If that is not the case then I don't see any
relevance to configure them under resident IdP configurations as well.

Thanks & Regards,
Johann.

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture][IAM] Moving File Based Artifacts to Artifact Store

[Johann Nallathamby]

+1 to get rid of the artifacts for user stores. I think this was a wrong
decision we made early on.

On Tue, Jun 4, 2019 at 1:19 PM Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi All,
>
> *Problem *
> Currently, some artifacts like userstores , tenants' data, etc are stored
> in the file system (not in the database). So when using a clustered setup
> those artifacts should be shared among all the nodes by using one of the
> following file sharing mechanisms.
>
>- Dep Sync
>- rSync
>- Shared File System
>
>
> *Solution *
> In order to avoid a shared file system and to reduce the deployment and
> maintenance overhead, those artifacts ca be persisted in the database
> itself.
>
> *Approach*
> After discussing with @Ruwan Abeykoon   and @Isura
> Karunaratne  we have two options to persist above
> discussed artifact details.
>
>- In the configuration store which is already implemented as discussed
>in [1][2].
>- In a separate table structure.
>
> If we are to go with option 01, then we need to consider the artifacts as
> configurations and persist in the existing schema.
>
The advantage of using this is we can re-use the existing implementation
> including the database schema and existing rest APIs and functionalities
> (pagination, searching, etc) .
>


> The drawback is the conceptual difference between an artifact and
> configuration.
>

I think this is not a problem. In fact I believe we made a wrong decision
of considering user stores as artifacts. I can't remember exactly as to why
we decided like that. User stores are not development artifacts; they are
one time configurations. They don't have metadata, versioning, lifecycles
or any other properties associated with other artifacts in WSO2.


> Further if we are to use the configuration store there is no way to
> include specific input validations for the user store configuration feature.
>

I am not sure I completely understand this. But please check the SAML2
metadata for identity provider feature where I believe we've done some
validations on the properties. I think they were done through interceptors
in identity provider service.


>
> If we are to go with the option 02, then the flow will be as follows.
>
> *Existing Flow*
>
> [image: Untitled Diagram (9).png]
>
>
>
>
>
>
> *Suggested Flow*
>
> [image: Untitled Diagram (10).png]
>
>
>
>- With the suggested approach, as the storage mechanisms, file system
>and database can be used and any other storage mechanism is pluggable.
>
> I don't agree with classifying user stores as artifacts. Therefore I guess
for me this option doesn't qualify at all :).

However, just to understand this option better, have we come across any
customer who has asked us to support multiple types of storage mechanisms
for artifacts and/or configurations? Where is this requirement coming from?
I've only seen such requirements for user stores. For configurations I feel
this is just over engineering. May be it is a valid requirement for
artifacts? Even if we agree that there are valid reasons to support this
then it has to be supported for all configurations and/or artifacts.

>
>- There should be a way to identify the repository where the data is
>loaded from. The repository can be the file system, database or any other
>storage mechanism.
>
> It sounds like this can get too complicated.

>
>- In both the read write operations the enduser should have the
>control to decide the storage mechanism.
>
> Hmm.. this sounds more like a requirement to optimize database read write
performance. Doesn't sound right for artifacts.

>
>- If the user needs to migrate a userstore from one storage mechanism
>(file system) to another then they can do it via UI.
>
> Again too many options for the user can make the product fragile.


> When persisting the data in the database there are two options we can use :
>
>- Persist data as a blob
>
> If we persist as blob then we lose the granular control over each property
for validation, transformation, etc.

>
>- Persists data as key value pair
>
> +1 for this.


> If we are to go with the option one then we can persist the file as a blob
> and reuse most of the existing parsing logics.
>

Given the understanding I think I prefer option 1 with properties.

Thanks & Regards,
Johann.


>
> Highly appreciate your suggestions and feedbacks on the above approach.
>
> [1] [Architecture][IAM][JDBC based Configuration Store] Database Schema
> [2] [Architecture] [IS] JDBC based Configuration Store for WSO2 IS
>
> Thanks,
> Hasanthi
>
> --
>
> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>
>

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org

Re: [Dev] Authenticate to provision a user with OAuth with sufficient privileges fails

[Johann Nallathamby]

Hi Farasath,

On Thu, Apr 25, 2019 at 9:26 AM Farasath Ahamed  wrote:

>
>
> On Thu, Apr 25, 2019 at 7:32 AM Johann Nallathamby 
> wrote:
>
>> Hi Malithi,
>>
>> On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby 
>>> wrote:
>>>
>>>> First of all, I don't understand what is the design issue with using
>>>> OAuth2 as a handler in authenticating and authorizing access to Rest APIs
>>>> by a client? Isn't that what OAuth2 is meant for typically?
>>>>
>>>
>>> Why should an access token just be used to get the authenticated
>>> subject, and that is also from introspection where that username is optional
>>>
>>
>> Using the access token to authenticate the client at the resource server
>> is one of the design principle behind OAuth2 right?
>>
>
> What do we mean by the client here? is it the OAuth client or the end user?
>

OAuth2 client. The application or service provider.


> In both cases, there is no *authentication* when the token is presented
> at the resource server
>

*There is authentication*. The client is authenticating to the resource
server by means of the access token. The bearer token is a reference token
that refers to the client's client_id. You can't be authorized unless you
have been authenticated.


> (In our case resource server is the REST valve and authorization server is
> IS), isn't it?
>

Yes, correct.


>
> And if the access token was obtained using client_credentials grant flow,
>> the authenticated subject would be in fact the application owner in our
>> implementation, which is also perfectly fine, because we don't intend to
>> bring any other authorization server for this use case. Similarly relying
>> on optional 'username' parameter of introspection response, is also
>> perfectly fine IMO, because again we never intend to replace our
>> authorization server with a 3rd party in this use case.
>>
>
> This is not entirely correct.
>
> Since 'username' is optional based on privacy concerns we already have
> requests for the possibility of masking the user information from the
> introspection response. If we decide to support masking the user
> information, then this current design of extracting user information based
> on introspection response will break.
>

How do you plan to mask? If by masking you mean introducing an opaque
identifier for the user, that won't impact this design. The the
authorization also will be based on the new opaque identifier. Similar
discussion I brought up on [1] as well.


> Also, we need to think about user consent on sharing claims/attributes in
> introspection response too. We do not have this at the moment but we might
> need to support it in future. Since the username is optional in
> introspection response, it can be returned or not based on user consent.
> This would break once again break the current design.
>

This has already been reported [2].

[1] "[IAM] Recommendation on WSO2 Usernames and Login names" in
support-dev-gr...@wso2.com
[2] https://support.wso2.com/jira/browse/SECINTDEV-212

Thanks & Regards,
Johann.


>
>
>>
>>> Why not use the access token for authorization it self. Isn't that how
>>> OAuth2 should be used
>>>
>>
>> With regards to authorization, OAuth2 specifies a way for the client to
>> request authorization from authorization server and a way to delegate
>> authorization to client by the authorization server, via scopes. However,
>> how this authorization levels / scopes are interpreted is left to our
>> desired implementation. It is the authorization server policy which decides
>> what level of authorization the client will get, even if the client doesn't
>> request for any scope. So in this use case our authorization server policy
>> says, grant the authorization levels to the client based on the
>> authorization levels (permissions) of the application owner. This means all
>> the applications which are created by same user will inherit the same set
>> of permissions from that user. Do you see a problem in assuming this policy?
>>
>> I haven't thoroughly thought through about the impact of this policy in a
>> 3 legged OAuth2 grant flow for the use case of securing product APIs, in
>> which case the authenticated subject will be the resource owner, and (s)he
>> might have a different set of permissions than the application owner. But
>> still I don't think it will create any issues with this policy. Do holler
>> if you see any issue there.
>>
>

Re: [Dev] Authenticate to provision a user with OAuth with sufficient privileges fails

[Johann Nallathamby]

Hi Malithi,

On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe 
wrote:

>
>
> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby 
> wrote:
>
>> First of all, I don't understand what is the design issue with using
>> OAuth2 as a handler in authenticating and authorizing access to Rest APIs
>> by a client? Isn't that what OAuth2 is meant for typically?
>>
>
> Why should an access token just be used to get the authenticated subject,
> and that is also from introspection where that username is optional
>

Using the access token to authenticate the client at the resource server is
one of the design principle behind OAuth2 right? And if the access token
was obtained using client_credentials grant flow, the authenticated subject
would be in fact the application owner in our implementation, which is also
perfectly fine, because we don't intend to bring any other authorization
server for this use case. Similarly relying on optional 'username'
parameter of introspection response, is also perfectly fine IMO, because
again we never intend to replace our authorization server with a 3rd party
in this use case.


> Why not use the access token for authorization it self. Isn't that how
> OAuth2 should be used
>

With regards to authorization, OAuth2 specifies a way for the client to
request authorization from authorization server and a way to delegate
authorization to client by the authorization server, via scopes. However,
how this authorization levels / scopes are interpreted is left to our
desired implementation. It is the authorization server policy which decides
what level of authorization the client will get, even if the client doesn't
request for any scope. So in this use case our authorization server policy
says, grant the authorization levels to the client based on the
authorization levels (permissions) of the application owner. This means all
the applications which are created by same user will inherit the same set
of permissions from that user. Do you see a problem in assuming this policy?

I haven't thoroughly thought through about the impact of this policy in a 3
legged OAuth2 grant flow for the use case of securing product APIs, in
which case the authenticated subject will be the resource owner, and (s)he
might have a different set of permissions than the application owner. But
still I don't think it will create any issues with this policy. Do holler
if you see any issue there.

Hope I understood your concerns and hope I clarified them.

Thanks & Regards,
Johann.


>
>>
>> Secondly, I think if the use case contains secondary user stores and
>> client expects to call out product APIs like SCIM, it is not wrong to
>> expect to have the checkbox on for those service providers. I don't see a
>> big issue in having that expectation really.
>>
>> Regards,
>> Johann.
>>
>> On Wed, Apr 24, 2019 at 8:02 PM Malithi Edirisinghe 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon  wrote:
>>>
>>>> Hi All,
>>>> Is that mean we use the same token to authentication(of the app) and
>>>> authorization (for the resource), both?
>>>>
>>>
>>> Well actually the case is, we have implemented a mechanism to allow
>>> access for resources (REST APIs) with an OAuth2 access token.
>>> Case is, this design is such that the access token is used to retrieve
>>> the user (from introspection), and rather than authorizing based on the
>>> access token, a separate authorization API is used to identify whether that
>>> respective user is authorized to the respective resource.
>>>
>>>
>>>>
>>>> Cheers,
>>>> Ruwan A
>>>>
>>>> On Wed, Apr 24, 2019 at 1:49 PM Malithi Edirisinghe 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe <
>>>>>> malit...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Yes, the major problem here is using an oauth token to get the user
>>>>>>> realm and using it later for authorization.
>>>>>>> OAuth is for authorization, in that aspect IMO, we need to re-design
>>>>>>> this handler.
>>>>>>>
>>>>>>> However, to come across with present issue with less effort I have
>>>>>>> below suggestion.
>>>>>>> I think i

Re: [Dev] Authenticate to provision a user with OAuth with sufficient privileges fails

[Johann Nallathamby]

First of all, I don't understand what is the design issue with using OAuth2
as a handler in authenticating and authorizing access to Rest APIs by a
client? Isn't that what OAuth2 is meant for typically?

Secondly, I think if the use case contains secondary user stores and client
expects to call out product APIs like SCIM, it is not wrong to expect to
have the checkbox on for those service providers. I don't see a big issue
in having that expectation really.

Regards,
Johann.

On Wed, Apr 24, 2019 at 8:02 PM Malithi Edirisinghe 
wrote:

>
>
> On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon  wrote:
>
>> Hi All,
>> Is that mean we use the same token to authentication(of the app) and
>> authorization (for the resource), both?
>>
>
> Well actually the case is, we have implemented a mechanism to allow access
> for resources (REST APIs) with an OAuth2 access token.
> Case is, this design is such that the access token is used to retrieve the
> user (from introspection), and rather than authorizing based on the access
> token, a separate authorization API is used to identify whether that
> respective user is authorized to the respective resource.
>
>
>>
>> Cheers,
>> Ruwan A
>>
>> On Wed, Apr 24, 2019 at 1:49 PM Malithi Edirisinghe 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed 
>>> wrote:
>>>


 On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe 
 wrote:

> Hi All,
>
> Yes, the major problem here is using an oauth token to get the user
> realm and using it later for authorization.
> OAuth is for authorization, in that aspect IMO, we need to re-design
> this handler.
>
> However, to come across with present issue with less effort I have
> below suggestion.
> I think if it needs to pick up the user info, it should access the
> user info endpoint with the token and get the realm information from there
> (user store domain, tenant domain) and that info then can be used to
> authorize the user in latter means.
>

 So this means only OAuth tokens obtained with "openid" scopes can be
 used for authentication at the REST valve right?

>>>
>>> Yes. As this model expects authentication I think that would be a better
>>> way to proceed with the current one we have. Only a short term solution.
>>>
>>>
>>> Do we have realm information in user info response? IIRC we included
 realm information in the id_token only with a recent fix.

>>>
>>> Yes, that is correct. But, IMO, it is something good to be incorporated
>>> to user info.
>>> WDYT?
>>>
>>>

 Thanks,
> Malithi
>
> On Wed, Apr 24, 2019 at 12:58 PM Isuranga Perera 
> wrote:
>
>> All:
>> With regards $subject[1]
>>
>> Here we have authentication flow and authorization flow. Token
>> validation service is used at authentication and username is set by the
>> validator. However, when "Use user store domain in local subject
>> identifier" is not enabled in Local & Outbound Authentication
>> Configuration usernames of secondary user-store users are set
>> without the domain parameter.
>> Since the user realm is configured depending on the tenant name when
>> authorizing secondary user store users at Authorization Valve suffering
>> from a caching issue which resulted in permission update ignorance.
>> This issue is not affected to tenant users as the tenant is
>> explicitly appended to the username at the time of authentication.
>>
>> $subject can be overcome by enabling "Use user store domain in local
>> subject identifier" in Local & Outbound Authentication Configuration
>>
>>
>> However one of the main issues is OAuth token is used to authenticate
>> the user in AuthenticationValve. We have to reaccess the validity of this
>> design approach as well.
>>
>>
>> Please provide your feedback on the $subject.
>>
>>
>> [1] https://github.com/wso2/product-is/issues/5078
>>
>>
>> Best Regards
>>
>> Isuranga Perera
>>
>> --
>> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>>  +94 71 735 7034 | isura...@wso2.com 
>>
>>
>
> --
>
> *Malithi Edirisinghe*
> Technical Lead
> WSO2 Inc.
>
> Mobile : +94 (0) 718176807
> malit...@wso2.com
>


 --
 Farasath Ahamed
 Senior Software Engineer, WSO2 Inc.; http://wso2.com
 Mobile: +94777603866
 Blog: https://farasath.blogspot.com / https://medium.com/@farasath
 Twitter: @farazath619 
 




>>>
>>> --
>>>
>>> *Malithi Edirisinghe*
>>> Technical Lead
>>> WSO2 Inc.
>>>
>>> Mobile : +94 (0) 718176807
>>> malit...@wso2.com
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>
> --
>
> *Malithi 

[Dev] [IAM] "Approve" option and consent don't work well together

[Johann Nallathamby]

Issue:
https://github.com/wso2/product-is/issues/5066

Thanks & Regards,
Johann.

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Issue when enabling Resend OTP link

[Johann Nallathamby]

Many systems I have seen always have the resend OTP option enabled, whether
or not the user has entered a wrong OTP. I guess this is because sometimes
the user might not receive the OTP in his mobile due to network
connectivity issues with the mobile provider. This will be a good
improvement to have.

Thanks & Regards,
Johann.

On Mon, Mar 4, 2019 at 10:37 AM Buddhima Udaranga 
wrote:

> Hi Prayag,
>
> Thank you for your email we will check this and get back to you
>
> Regards
> *Buddhima Udaranga*|Software Engineer| WSO2 Inc. 
> (M)+94 714742094 | (E) buddhi...@wso2.com
> 
>
>
> On Mon, Mar 4, 2019 at 10:34 AM Isura Karunaratne  wrote:
>
>> + @Buddhima Udaranga 
>>
>> On Wed, Feb 13, 2019 at 6:20 PM prayag pavithran <
>> prayagpavith...@hotmail.com> wrote:
>>
>>> Hi ,
>>>
>>> Currently we've integrated WSO2 identity server with 2 factor
>>> authentication (*Email OTP*) configured .
>>>
>>> In *emailotp.jsp *page "Resend Code" hyper link is enabled only if user
>>> enters wrong OTP. This functionality works fine.
>>>
>>> We would like to enable "*Resend Code"* link when ever user  lands in
>>> Email OTP screen.
>>>
>>> Once we removed the condition check for enabling Resend OTP link , the
>>> link gets displayed when user lands in the email OTP screen.
>>>
>>> This time when user clicks the link the user is navigated to
>>> /commonauth   blank screen.
>>>
>>> Kindly request you to help me solving the issue .
>>>
>>>
>>> Thanks & Regards,
>>> Prayag Pavithran
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2 
>> *lean.enterprise.middleware*
>> Email: is...@wso2.com
>> Mob : +94 772 254 810
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] InCommon Federation Compliance for WSO2IS - UI Component

[Johann Nallathamby]

Hi Sahan,

Two concerns here:
1. Is the placement of the feature in the menu correct?
2. I don't know if it was intensional, but isn't it better to avoid
InCommon logos and only label it using standard federation terminology?
Because we haven't done it like that so far for other profiles such as
eIDAS. But again I don't know if this is intensional to get traction to the
product.

Regards,
Johann.

On Wed, Sep 26, 2018 at 8:26 AM Sahan Gunathilaka  wrote:

> Hi All,
> One of the major requirements to comply WSO2 IS with InCommon Federation
> is to support *auto refreshment* of metadata of participating Service
> Providers and Identity Providers at IS. Following is the designed UI to
> provide this requirement.
>
> [image: Screenshot_2018-09-26 WSO2 Management Console.png]
>
> *"Enable Auto Refresh*" check box and "*Refresh Time*" drop box can be
> set to automate the refreshing cycle. All service providers' and identity
> providers' configurations will be updated according to them after clicking
> on "*Save*" button.
>
> "*Force Refresh*" button lets users to refresh metadata instantly based
> on the latest update of metadata file at the InCommon Federation.
>
> "*Clear All*" button will remove all the configured data and result "0"
> for both "Total Service Providers" and "Total Identity Providers" in the
> table.
>
> If you have any suggestion on this, please let me know.
>
> Thank you!
> Best Regards!
>
> --
> *Sahan Gunathilaka*
> Intern - Software Engineering
> *WSO2*
> mobile:  +94776343266
>
> [image: http://wso2.com/signature]
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Configuring Different Federated Identity Providers for My Enterprise Customers

[Johann Nallathamby]

Hi Pulasthi,

Thanks for the answer. This seems to be like a viable option if we upgrade.

Regards,
Johann.

On Thu, Jul 19, 2018 at 11:46 PM Pulasthi Mahawithana 
wrote:

> Hi Johann,
>
> If the customers that have their own IdPs is of less amount, we can
> achieve this with an authentication script with the features we already
> have OOTB for IS 5.7.0.
>
> The approach would be,
>
>1. Configure the outbound authentication to have identifier first
>followed by a step with multiple options representing basic
>authenticator(for customers using IS itself) and customer IDPs.
>2. At script, get user's identifier first and get the corresponding
>tenant domain.
>3. Check if there is a customer IdP for above tenant (using some
>mapping maintained internally or at script), if not use local IdP (basic
>auth) as default
>4. From the script, limit the authentication options of the steps we
>configured, just to use the IdP from step 3.
>
>
> If there are many tenants/customers using their own IDPs, the above
> solution will not be a good one, as it will be hard to configure and
> maintain. For those cases, instead of filtering out options at step 4
> above, we can write and use a custom function to dynamically inject the IdP
> configured for the tenant at step 3.
>
> On Thu, Jul 19, 2018 at 8:15 PM Johann Nallathamby 
> wrote:
>
>> Ping on this please!
>>
>> On Wed, Jul 18, 2018 at 5:26 PM Johann Nallathamby 
>> wrote:
>>
>>> Hi IAM Team,
>>>
>>> Following is the use case I want to accomplish. But I am not able to
>>> figure out how I would be able to do it.
>>>
>>> I have IS running with multiple tenants. Each tenant is an enterprise
>>> customer of mine. I have a SaaS application registered in super tenant that
>>> all my customers can access. Currently all my customers can login to this
>>> application using their credentials registered in IS.
>>>
>>> What I want be able to do now is, federate the logins to my customer's
>>> on-premise identity provider, so that I don't have to manage separate
>>> passwords for them and the customers' users can use their enterprise
>>> credentials to access my application as well.
>>>
>>> *Condition:* Some customers may still want to continue using IS's
>>> credential store, while some other customers may want to integrate their
>>> on-premise identity providers.
>>>
>>> How could I accomplish this scenario?
>>>
>>> Thanks & Regards,
>>> Johann.
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile: *+94 77 7776950*
>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>> Medium: *https://medium.com/@johann_nallathamby
>>> <https://medium.com/@johann_nallathamby>*
>>> Twitter: *@dj_nallaa*
>>>
>>
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: *+94 77 7776950*
>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>> <http://www.linkedin.com/in/johann-nallathamby>*
>> Medium: *https://medium.com/@johann_nallathamby
>> <https://medium.com/@johann_nallathamby>*
>> Twitter: *@dj_nallaa*
>>
>
>
> --
> *Pulasthi Mahawithana*
> Associate Technical Lead
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: https://medium.com/@pulasthi7/
>
> <https://wso2.com/signature>
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Configuring Different Federated Identity Providers for My Enterprise Customers

[Johann Nallathamby]

Hi Malithi,

This is something I also thought about, but it won't be an option in this
case, because something else I didn't say is, we have a customized IS where
a user can belong to multiple tenants, and user selects the tenant which
(s)he wants to login after the username/password validation. So until the
user is identified the application doesn't have a way to identify the
tenant of the user.

If this customization wasn't there what you say would be an option for this
case.

Regards,
Johann.

On Fri, Jul 20, 2018 at 7:51 AM Malithi Edirisinghe 
wrote:

> Hi Johann,
>
> As the customer onboards, which means a tenant onboards in this case, we
> can onboard the application for the tenant rather than keeping it SaaS.
> That would also be an option I think. It's easy to manage customer
> specific authentication sequences for the respective application then.
>
> Thanks,
> Malithi.
>
> On Thu, Jul 19, 2018 at 11:45 PM, Pulasthi Mahawithana  > wrote:
>
>> Hi Johann,
>>
>> If the customers that have their own IdPs is of less amount, we can
>> achieve this with an authentication script with the features we already
>> have OOTB for IS 5.7.0.
>>
>> The approach would be,
>>
>>1. Configure the outbound authentication to have identifier first
>>followed by a step with multiple options representing basic
>>authenticator(for customers using IS itself) and customer IDPs.
>>2. At script, get user's identifier first and get the corresponding
>>tenant domain.
>>3. Check if there is a customer IdP for above tenant (using some
>>mapping maintained internally or at script), if not use local IdP (basic
>>auth) as default
>>4. From the script, limit the authentication options of the steps we
>>configured, just to use the IdP from step 3.
>>
>>
>> If there are many tenants/customers using their own IDPs, the above
>> solution will not be a good one, as it will be hard to configure and
>> maintain. For those cases, instead of filtering out options at step 4
>> above, we can write and use a custom function to dynamically inject the IdP
>> configured for the tenant at step 3.
>>
>> On Thu, Jul 19, 2018 at 8:15 PM Johann Nallathamby 
>> wrote:
>>
>>> Ping on this please!
>>>
>>> On Wed, Jul 18, 2018 at 5:26 PM Johann Nallathamby 
>>> wrote:
>>>
>>>> Hi IAM Team,
>>>>
>>>> Following is the use case I want to accomplish. But I am not able to
>>>> figure out how I would be able to do it.
>>>>
>>>> I have IS running with multiple tenants. Each tenant is an enterprise
>>>> customer of mine. I have a SaaS application registered in super tenant that
>>>> all my customers can access. Currently all my customers can login to this
>>>> application using their credentials registered in IS.
>>>>
>>>> What I want be able to do now is, federate the logins to my customer's
>>>> on-premise identity provider, so that I don't have to manage separate
>>>> passwords for them and the customers' users can use their enterprise
>>>> credentials to access my application as well.
>>>>
>>>> *Condition:* Some customers may still want to continue using IS's
>>>> credential store, while some other customers may want to integrate their
>>>> on-premise identity providers.
>>>>
>>>> How could I accomplish this scenario?
>>>>
>>>> Thanks & Regards,
>>>> Johann.
>>>>
>>>> --
>>>>
>>>> *Johann Dilantha Nallathamby*
>>>> Senior Lead Solutions Engineer
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile: *+94 77 7776950*
>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>>> Medium: *https://medium.com/@johann_nallathamby
>>>> <https://medium.com/@johann_nallathamby>*
>>>> Twitter: *@dj_nallaa*
>>>>
>>>
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile: *+94 77 7776950*
>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>> Medium: *https://medium.com/@johann_nallathamby
>>> <https://medium.com/@johann_nallathamby>*
>>> Twitter: *@dj_nallaa*
>>>
>>
>>
>> --
>> *Pulasthi Mahawithana*
>> Associate Technical Lead
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: https://medium.com/@pulasthi7/
>>
>> <https://wso2.com/signature>
>>
>
>
>
> --
>
> *Malithi Edirisinghe*
> Associate Technical Lead
> WSO2 Inc.
>
> Mobile : +94 (0) 718176807
> malit...@wso2.com
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Configuring Different Federated Identity Providers for My Enterprise Customers

[Johann Nallathamby]

Ping on this please!

On Wed, Jul 18, 2018 at 5:26 PM Johann Nallathamby  wrote:

> Hi IAM Team,
>
> Following is the use case I want to accomplish. But I am not able to
> figure out how I would be able to do it.
>
> I have IS running with multiple tenants. Each tenant is an enterprise
> customer of mine. I have a SaaS application registered in super tenant that
> all my customers can access. Currently all my customers can login to this
> application using their credentials registered in IS.
>
> What I want be able to do now is, federate the logins to my customer's
> on-premise identity provider, so that I don't have to manage separate
> passwords for them and the customers' users can use their enterprise
> credentials to access my application as well.
>
> *Condition:* Some customers may still want to continue using IS's
> credential store, while some other customers may want to integrate their
> on-premise identity providers.
>
> How could I accomplish this scenario?
>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> <http://www.linkedin.com/in/johann-nallathamby>*
> Medium: *https://medium.com/@johann_nallathamby
> <https://medium.com/@johann_nallathamby>*
> Twitter: *@dj_nallaa*
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Configuring Different Federated Identity Providers for My Enterprise Customers

[Johann Nallathamby]

Hi IAM Team,

Following is the use case I want to accomplish. But I am not able to figure
out how I would be able to do it.

I have IS running with multiple tenants. Each tenant is an enterprise
customer of mine. I have a SaaS application registered in super tenant that
all my customers can access. Currently all my customers can login to this
application using their credentials registered in IS.

What I want be able to do now is, federate the logins to my customer's
on-premise identity provider, so that I don't have to manage separate
passwords for them and the customers' users can use their enterprise
credentials to access my application as well.

*Condition:* Some customers may still want to continue using IS's
credential store, while some other customers may want to integrate their
on-premise identity providers.

How could I accomplish this scenario?

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Showing the Secret Key along with the QR code in the TOTP Login Page

[Johann Nallathamby]

Folks,

Please check if this is something we can do. Reason is it allows users to
use the Google authenticator and enroll for TOTP, while browsing a web site
in the mobile browser for the first time.

I am not sure if there are other alternatives, like taking a screenshot of
the QR code and then selecting it from the photo gallery and giving it to
the Google authenticator.

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Johann Nallathamby]

> wrote:
>
>>
>>
>> On Wed, Feb 28, 2018 at 5:15 PM, Dulanja Liyanage <dula...@wso2.com>
>> wrote:
>>
>>> If extensions are coming in the SAML AuthnRequest from the SP, then,
>>> IIRC, that *same extension* will be copied to the AuthnRequest going to
>>> the Federated IdP. Is that behaviour acceptable for this scenario? Please
>>> validate that.
>>>
>>
>> If that is a federated scenario, where the IDP is not IS, we need to
>> disable the eIDAS extension processing and just forwarded the request as it
>> is.
>>
>>
>>>
>>> On Wed, Feb 28, 2018 at 7:56 AM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Hi Indunil,
>>>>
>>>> On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake <
>>>> indu...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> eIDAS (electronic IDentification, Authentication and trust Services)
>>>>> is an EU regulation on electronic identification and trust services for
>>>>> electronic transactions in the internal market. The eIDAS interoperability
>>>>> framework including its national entities (eIDAS-Connector and
>>>>> eIDAS-Service) need to exchange messages including personal and technical
>>>>> attributes to support cross-border identification and authentication
>>>>> processes (Please refer [1] for more information). For the exchange of
>>>>> messages, the use of the SAML 2.0 specifications has been agreed and there
>>>>> are eIDAS compliant set of technical specifications in [2], which Member
>>>>> States of EU to use to develop their own eIDAS-compliant implementation.
>>>>>
>>>>>
>>>>> As per the "eIDAS SAML Message Format" specification, handling and
>>>>> inclusion of attributes into exchanged messages is defined as follows.
>>>>>
>>>>>- Attributes MUST be requested as  and 
>>>>> *
>>>>>MUST be included in the  element of the SAML
>>>>>AuthnRequest.*
>>>>>
>>>>> Ex:
>>>>>
>>>>> >>>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
>>>>> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
>>>>> <http://eidas.europa.eu/saml-extensions>"* ...>
>>>>>  
>>>>>  **
>>>>>*public*
>>>>>   **
>>>>>  >>>>   
>>>>> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>>>>>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>>>>> isRequired="false" />
>>>>>  >>>>   
>>>>> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>>>>>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>>>>> isRequired="true" />
>>>>>
>>>>>  
>>>>>  .
>>>>> 
>>>>>
>>>>>
>>>>>- Apart from the attributes, for indicating whether an
>>>>>authentication request is made by a private sector or public sector 
>>>>> SP, the
>>>>>defined element * MUST be present* either in the
>>>>> element of SAML metadata or in the 
>>>>>element of a .
>>>>>
>>>>>
>>>>> As per the SAML Core specification in [3], SAML Extensions is an
>>>>> optional element in SAML 2.0, allowing arbitrary information to be passed
>>>>> to the identity provider which are agreed on between the communicating
>>>>> parties. As mentioned above, eIDAS attributes should be included within
>>>>> SAML extension element.
>>>>>
>>>>>
>>>>> Currently in IS, *SAML Extensions processing *has not taken into the
>>>>> consideration. So that, in order to have eIDAS profile support for SAML,
>>>>> that should be considered. Please find the following proposed
>>>>> implementation.
>>>>>
>>>>>1. *Register a set of SAML Extension Processors* - extensible
>>>>>mechanism where we can include any extension processing
>>>>>2. *eIDAS Exten

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Johann Nallathamby]

Hi Indunil,

On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> eIDAS (electronic IDentification, Authentication and trust Services) is an
> EU regulation on electronic identification and trust services for
> electronic transactions in the internal market. The eIDAS interoperability
> framework including its national entities (eIDAS-Connector and
> eIDAS-Service) need to exchange messages including personal and technical
> attributes to support cross-border identification and authentication
> processes (Please refer [1] for more information). For the exchange of
> messages, the use of the SAML 2.0 specifications has been agreed and there
> are eIDAS compliant set of technical specifications in [2], which Member
> States of EU to use to develop their own eIDAS-compliant implementation.
>
>
> As per the "eIDAS SAML Message Format" specification, handling and
> inclusion of attributes into exchanged messages is defined as follows.
>
>- Attributes MUST be requested as  and 
> *
>MUST be included in the  element of the SAML
>AuthnRequest.*
>
> Ex:
>
>  xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
> <http://eidas.europa.eu/saml-extensions>"* ...>
>  
>  **
>*public*
>   **
> 
> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="false" />
> 
> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="true" />
>
>  
>  .
> 
>
>
>- Apart from the attributes, for indicating whether an authentication
>request is made by a private sector or public sector SP, the defined
>element * MUST be present* either in the 
>element of SAML metadata or in the  element of a
>.
>
>
> As per the SAML Core specification in [3], SAML Extensions is an optional
> element in SAML 2.0, allowing arbitrary information to be passed to the
> identity provider which are agreed on between the communicating parties. As
> mentioned above, eIDAS attributes should be included within SAML extension
> element.
>
>
> Currently in IS, *SAML Extensions processing *has not taken into the
> consideration. So that, in order to have eIDAS profile support for SAML,
> that should be considered. Please find the following proposed
> implementation.
>
>1. *Register a set of SAML Extension Processors* - extensible
>mechanism where we can include any extension processing
>2. *eIDAS Extension Processor *- specifically handled the eIDAS
>extension
>3. *Invoke the processors when building the SAML assertion*
>   - Consider that all the necessary attributes are configured as the
>   SP requested claims
>- In the eIDAS processor, filtering out the requested attributes based
>   on the "RequestedAttributes" elements in the authentication request
>
>
+1 for the approach. But make sure we don't have to configure FQCN in files
and make only one processor work at a given time. Processors should be
picked dynamically based on the request. I think like the other processors
we have, you can extend from AbtractIdentityHandler and do this via the
HandlerManager we have in identity.core.

One of the concerns I have is about "RequestedAttributes". We are assuming
that the required attributes are configured for the service providers. This
coordination is not possible between countries, unless they all agree on a
standard set of attributes always, and there are too many service providers
to do this. I think we need to fix this and have a way to dynamically
request attributes without depending on the service provider configuration.
OIDC also suffers from this same limitation. I think we need to fix this
problem with this effort.

Regards,
Johann.

>
>-
>
>
> Really appreciate your suggestions and comments.
>
>
> [1] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+
> does+it+work+-+eIDAS+solution
> [2] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/
> 2016/12/16/eIDAS+Technical+Specifications+v.+1.1
> [3] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
>
> Thanks and Regards
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>



-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Johann Nallathamby]

pon successful authentication and
>>>>>> authorization. So simply even if the user is authenticated for the very
>>>>>> first time, we will not set the cookie unless the user is authorized to
>>>>>> access that particular application. (This only applies to the very first
>>>>>> app the user is trying to login)
>>>>>>
>>>>>> WDYT ?
>>>>>>
>>>>>>
>>>>>> [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
>>>>>> ontrol+Policy+for+a+Service+Provider
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Hasintha Indrajee
>>>>>> WSO2, Inc.
>>>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ishara Karunarathna
>>>>> Technical Lead
>>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>>
>>>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>>>> +94717996791 <071%20799%206791>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Hasintha Indrajee
>>>> WSO2, Inc.
>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791 <071%20799%206791>
>>>
>>>
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
> Ishara Karunarathna
> Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Defining Two Regex Patterns in User Store Configuration and Claim Configuration is Wrong

[Johann Nallathamby]

On Tue, Jan 23, 2018 at 10:16 AM, Isura Karunaratne <is...@wso2.com> wrote:

> Hi Johann,
>
>
>
> On Tue, Jan 23, 2018 at 8:07 AM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi IAM Team,
>>
>> We have two regex patterns for user names and role names.
>>
>> 1. In the userstore configuration as "UsernameJavaRegex" and
>> "RolenameJavaRegex".
>>
>> 2. Similarly we have Regex property defined for claims and username -
>> http://wso2.org/claim/username and role name -
>> http://wso2.org/claims/role are claims as well.
>>
>
>> Can we not have two places to define regex for these two claims? How come
>> we don't need to define regex for other user attributes in the user store
>> configuration? Why is username (and role name) special?
>>
>>
> Also we have separate Javascript Regex properties for username and role
>> name. Why don't we have the same for other attributes? If so can't we
>> introduce that as another claim property to be consistent and easy to
>> understand for users?
>>
>
> RolenameJavaRegex is different from the regrex defined in
> http://wso2.org/claims/role claim, bacause that claim is used to store
> all the roles the perticular user is assigned. RolenameJavaRegex will be
> applied to a single role.
>
> Ex. role calim value.  --> Internal/everyone,admin,Application/
> travelocity.com
>

Hmm.. I don't think that could be a reason. Regex is defined for a single
value of a singular or multi-valued attribute. I don't think there is a
purpose to define a regex for the multi-valued string irrespective of how
you store it.


>
> Thanks
> Isura.
>
>
>>
>> Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: *+94 77 7776950*
>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>> <http://www.linkedin.com/in/johann-nallathamby>*
>> Medium: *https://medium.com/@johann_nallathamby
>> <https://medium.com/@johann_nallathamby>*
>> Twitter: *@dj_nallaa*
>>
>
>
>
> --
>
> *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/
>
>
>
>


-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Defining Two Regex Patterns in User Store Configuration and Claim Configuration is Wrong

[Johann Nallathamby]

Hi IAM Team,

We have two regex patterns for user names and role names.

1. In the userstore configuration as "UsernameJavaRegex" and
"RolenameJavaRegex".

2. Similarly we have Regex property defined for claims and username -
http://wso2.org/claim/username and role name - http://wso2.org/claims/role
are claims as well.

Can we not have two places to define regex for these two claims? How come
we don't need to define regex for other user attributes in the user store
configuration? Why is username (and role name) special?

Also we have separate Javascript Regex properties for username and role
name. Why don't we have the same for other attributes? If so can't we
introduce that as another claim property to be consistent and easy to
understand for users?

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Places we are using super tenant keystore

[Johann Nallathamby]

*[+Prasanna]*

There are resources in the registry that also get encrypted specific to
each product. Also some fields in the database which again is specific to
each product. To get an idea of what are those registry resources in each
product, you could take a look at the registry migration client we wrote
for the expired certificate issue.

Regards,
Johann.

On Tue, Jan 9, 2018 at 9:12 AM, Godwin Shrimal <god...@wso2.com> wrote:

> We use super tenant keystore for Secure vault.
>
>
> Thanks
> Godwin
>
> On Tue, Jan 9, 2018 at 10:19 AM, Godwin Shrimal <god...@wso2.com> wrote:
>
>> Hi Devs,
>>
>> What are the places(except tenant keystore password) we are using super
>> tenant keystore for encryption/decryption? I want to understand what is the
>> impact of changing a keystore in a running system.
>>
>> Thanks
>> Godwin
>>
>> --
>> *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/
>> <https://www.linkedin.com/in/godwin-amila-2ba26844/>*
>> twitter: https://twitter.com/godwinamila
>> <http://wso2.com/signature>
>>
>
>
>
> --
> *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/
> <https://www.linkedin.com/in/godwin-amila-2ba26844/>*
> twitter: https://twitter.com/godwinamila
> <http://wso2.com/signature>
>



-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

[Johann Nallathamby]

On Fri, Nov 17, 2017 at 7:08 PM, Farasath Ahamed <farasa...@wso2.com> wrote:

>
>
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
> On Fri, Nov 17, 2017 at 6:48 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe <malit...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Hi Farasath,
>>>>
>>>> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed <farasa...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby <joh...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Self contained JWT's may get quite large and if we set it as the
>>>>>> default size in the script, for users who are not using self contained 
>>>>>> JWT
>>>>>> also it is going to consume large space in the database.
>>>>>>
>>>>>> Did we think about storing a hash of the access token?
>>>>>>
>>>>>
>>>>> As pointed out by Johann JWT can grow large with requested claims etc.
>>>>> so changing the column size can happen as soon as the JWT exceeds the
>>>>> defined length,
>>>>>
>>>>> Therefore, We had few discussions offline on options to resolve this.
>>>>>
>>>>> 1. User a different data type like BLOB/TEXT to store the JWT access
>>>>> token and store a hash to improve search. In this approach we will avoid
>>>>> the SQL error, but there will be performance drop for normal UUID based
>>>>> access tokens.
>>>>>
>>>>
>>>> May be we can introduce a config to say whether we need to hash or not.
>>>>
>>>>
>>>>>
>>>>> 2. Not store the self contained access token in the database at
>>>>> all[1]. Since by definition the self contained access token has all the
>>>>> necessary data to validate it we can validate the token on IS during
>>>>> introspection. Ideally, the idea behind the self contained access token is
>>>>> to avoid introspection. But if required we can do it using the presented
>>>>> the JWT itself.(This is how client will validate the access token 
>>>>> anyways).
>>>>> Downfall of this approach is that we cannot revoke the token since we
>>>>> don't anyway keep any reference to the issued token.
>>>>>
>>>>
>>>> We can use the "jti" claim of the JWT as the reference and use it to
>>>> manage the token in IS.
>>>>
>>>
>>> So I think you meant that we don't need to persist the self contained
>>> access token at all (even the hash) and use an identifier to reference the
>>> token issued. And that reference will be returned with the JWT as 'jti'
>>> claim.
>>>
>>
>> Yes
>>
>
> So we can store the jti as the access_token in the IDN_ACCESS_TOKEN table.
> Is my understanding correct?
>

Yes :)


>
>
>>
>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>>
>>>>>
>>>>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
>>>>> encoded-access-tokens/
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fwww.oauth.com%2Foauth2-servers%2Faccess-tokens%2Fself-encoded-access-tokens%2F=D=1=AFQjCNF5pHN-sGoIgbANyG1WpbRC-dZfSA>
>>>>>
>>>>>
>>>>> Appreciate your thoughts!
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne <is...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Currently, ACCESS_TOKEN column length is defined as 5

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

[Johann Nallathamby]

On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe <malit...@wso2.com>
wrote:

>
>
> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi Farasath,
>>
>> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed <farasa...@wso2.com>
>> wrote:
>>
>>>
>>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Self contained JWT's may get quite large and if we set it as the
>>>> default size in the script, for users who are not using self contained JWT
>>>> also it is going to consume large space in the database.
>>>>
>>>> Did we think about storing a hash of the access token?
>>>>
>>>
>>> As pointed out by Johann JWT can grow large with requested claims etc.
>>> so changing the column size can happen as soon as the JWT exceeds the
>>> defined length,
>>>
>>> Therefore, We had few discussions offline on options to resolve this.
>>>
>>> 1. User a different data type like BLOB/TEXT to store the JWT access
>>> token and store a hash to improve search. In this approach we will avoid
>>> the SQL error, but there will be performance drop for normal UUID based
>>> access tokens.
>>>
>>
>> May be we can introduce a config to say whether we need to hash or not.
>>
>>
>>>
>>> 2. Not store the self contained access token in the database at all[1].
>>> Since by definition the self contained access token has all the necessary
>>> data to validate it we can validate the token on IS during introspection.
>>> Ideally, the idea behind the self contained access token is to avoid
>>> introspection. But if required we can do it using the presented the JWT
>>> itself.(This is how client will validate the access token anyways).
>>> Downfall of this approach is that we cannot revoke the token since we
>>> don't anyway keep any reference to the issued token.
>>>
>>
>> We can use the "jti" claim of the JWT as the reference and use it to
>> manage the token in IS.
>>
>
> So I think you meant that we don't need to persist the self contained
> access token at all (even the hash) and use an identifier to reference the
> token issued. And that reference will be returned with the JWT as 'jti'
> claim.
>

Yes


>
>
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
>>> encoded-access-tokens/
>>> <https://www.google.com/url?q=https%3A%2F%2Fwww.oauth.com%2Foauth2-servers%2Faccess-tokens%2Fself-encoded-access-tokens%2F=D=1=AFQjCNF5pHN-sGoIgbANyG1WpbRC-dZfSA>
>>>
>>>
>>> Appreciate your thoughts!
>>>
>>>
>>>
>>>>
>>>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is
>>>>>> not enough to store self-contained access token [2].
>>>>>>
>>>>>> Shall we increase the column size by default?
>>>>>>
>>>>>> Thanks
>>>>>> Isura.
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>>>>>> TOKEN_ID VARCHAR (255),
>>>>>> ACCESS_TOKEN VARCHAR(512),
>>>>>> REFRESH_TOKEN VARCHAR(512),
>>>>>> CONSUMER_KEY_ID INTEGER,
>>>>>> AUTHZ_USER VARCHAR (100),
>>>>>> TENANT_ID INTEGER,
>>>>>> USER_DOMAIN VARCHAR(50),
>>>>>> USER_TYPE VARCHAR (25),
>>>>>> GRANT_TYPE VARCHAR (50),
>>>>>> TIME_CREATED TIMESTAMP DEFAULT 0,
>>>>>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
>>>>>> VALIDITY_PERIOD BIGINT,
>>>>>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
>>>>>> TOKEN_SCOPE_HASH VARCHAR(32),
>>>>>> TOKEN_STATE V

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

[Johann Nallathamby]

Hi Farasath,

On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed <farasa...@wso2.com> wrote:

>
> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Self contained JWT's may get quite large and if we set it as the default
>> size in the script, for users who are not using self contained JWT also it
>> is going to consume large space in the database.
>>
>> Did we think about storing a hash of the access token?
>>
>
> As pointed out by Johann JWT can grow large with requested claims etc. so
> changing the column size can happen as soon as the JWT exceeds the defined
> length,
>
> Therefore, We had few discussions offline on options to resolve this.
>
> 1. User a different data type like BLOB/TEXT to store the JWT access token
> and store a hash to improve search. In this approach we will avoid the SQL
> error, but there will be performance drop for normal UUID based access
> tokens.
>

May be we can introduce a config to say whether we need to hash or not.


>
> 2. Not store the self contained access token in the database at all[1].
> Since by definition the self contained access token has all the necessary
> data to validate it we can validate the token on IS during introspection.
> Ideally, the idea behind the self contained access token is to avoid
> introspection. But if required we can do it using the presented the JWT
> itself.(This is how client will validate the access token anyways).
> Downfall of this approach is that we cannot revoke the token since we
> don't anyway keep any reference to the issued token.
>

We can use the "jti" claim of the JWT as the reference and use it to manage
the token in IS.

Regards,
Johann.


>
> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
> encoded-access-tokens/
> <https://www.google.com/url?q=https%3A%2F%2Fwww.oauth.com%2Foauth2-servers%2Faccess-tokens%2Fself-encoded-access-tokens%2F=D=1=AFQjCNF5pHN-sGoIgbANyG1WpbRC-dZfSA>
>
>
> Appreciate your thoughts!
>
>
>
>>
>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne <is...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is
>>>> not enough to store self-contained access token [2].
>>>>
>>>> Shall we increase the column size by default?
>>>>
>>>> Thanks
>>>> Isura.
>>>>
>>>>
>>>> [1]
>>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>>>> TOKEN_ID VARCHAR (255),
>>>> ACCESS_TOKEN VARCHAR(512),
>>>> REFRESH_TOKEN VARCHAR(512),
>>>> CONSUMER_KEY_ID INTEGER,
>>>> AUTHZ_USER VARCHAR (100),
>>>> TENANT_ID INTEGER,
>>>> USER_DOMAIN VARCHAR(50),
>>>> USER_TYPE VARCHAR (25),
>>>> GRANT_TYPE VARCHAR (50),
>>>> TIME_CREATED TIMESTAMP DEFAULT 0,
>>>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
>>>> VALIDITY_PERIOD BIGINT,
>>>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
>>>> TOKEN_SCOPE_HASH VARCHAR(32),
>>>> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
>>>> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
>>>> SUBJECT_IDENTIFIER VARCHAR(255),
>>>> PRIMARY KEY (TOKEN_ID),
>>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
>>>> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
>>>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TE
>>>> NANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
>>>>TOKEN_STATE,TOKEN_STATE_ID)
>>>>
>>>>
>>>> [2] https://wso2.org/jira/browse/IDENTITY-6917
>>>>
>>>>
>>>> --
>>>>
>>>> *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/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *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/
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

[Johann Nallathamby]

Self contained JWT's may get quite large and if we set it as the default
size in the script, for users who are not using self contained JWT also it
is going to consume large space in the database.

Did we think about storing a hash of the access token?

On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne  wrote:

>
>
> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne  wrote:
>
>> Hi all,
>>
>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is not
>> enough to store self-contained access token [2].
>>
>> Shall we increase the column size by default?
>>
>> Thanks
>> Isura.
>>
>>
>> [1]
>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>> TOKEN_ID VARCHAR (255),
>> ACCESS_TOKEN VARCHAR(512),
>> REFRESH_TOKEN VARCHAR(512),
>> CONSUMER_KEY_ID INTEGER,
>> AUTHZ_USER VARCHAR (100),
>> TENANT_ID INTEGER,
>> USER_DOMAIN VARCHAR(50),
>> USER_TYPE VARCHAR (25),
>> GRANT_TYPE VARCHAR (50),
>> TIME_CREATED TIMESTAMP DEFAULT 0,
>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
>> VALIDITY_PERIOD BIGINT,
>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
>> TOKEN_SCOPE_HASH VARCHAR(32),
>> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
>> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
>> SUBJECT_IDENTIFIER VARCHAR(255),
>> PRIMARY KEY (TOKEN_ID),
>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
>> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TE
>> NANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
>>TOKEN_STATE,TOKEN_STATE_ID)
>>
>>
>> [2] https://wso2.org/jira/browse/IDENTITY-6917
>>
>>
>> --
>>
>> *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/
>>
>>
>>
>>
>
>
> --
>
> *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/
>
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 Identity Server 5.4.0 Alpha 8 Released !!!

[Johann Nallathamby]

The Public JIRA version still says Alpha-8 "unreleased". Can we fix this?
And if we are planning for Alpha-9 can we add that as new version?

Regards,
Johann.

On Fri, Nov 10, 2017 at 1:26 AM, Jayanga Kaushalya 
wrote:

> The WSO2 Identity and Access Management team is pleased to announce the
> release of WSO2 Identity Server 5.4.0 Alpha 8.
>
> You can build the distribution from the source tag
> https://github.com/wso2/product-is/releases/tag/v5.4.0-alpha8 following
> the steps below.
>
>
> *Building from the source*
>
>1. Install Java8 or above
>2. Install Apache Maven 3.x.x(https://maven.apache.org/download.cgi#)
>3. Get a clone from https://github.com/wso2/product-is.git and
>checkout to v5.4.0-alpha8 tag or you can directly download the source for
>the tag from https://github.com/wso2/product-is/releases/tag/v5.4.
>0-alpha8
>4. Run the one of the below maven commands from product-is directory,
>   - *mvn** clean install* (To build the binary and source
>   distributions with the tests)
>   - *mvn** clean install -Dmaven.test.skip=true* (To build the binary
>   and source distributions, without running any of the unit/integration 
> tests)
>5. You can find the wso2is-5.4.0-alpha8.zip binary distribution in
>product-is/modules/distribution/target directory.
>
> The following list contains all the features, improvements, and bug fixes
> available with the WSO2 Identity Server 5.4.0 Alpha 8 release.
> Patch
>
>- [IDENTITY-6883 ] -
>MalformedURLException when wreply urls has a improper url value.
>
> Bug
>
>- [IDENTITY-6307 ] -
>Auth_time is changing to session updated time
>- [IDENTITY-6875 ] - role
>claim is missing with request path authentication for saml sp configuration
>
> Improvement
>
>- [IDENTITY-6239 ] -
>Improve Facebook\Google authenticators to handle claim transformation using
>a dedicated claim dialect
>
>
> *Contribute to WSO2 Identity Server*
>
> *Mailing Lists*
>
> Join our mailing lists and correspond with the developers directly. We
> also encourage you to take part in discussions related to the product in
> the architecture mailing list. If you have any questions regarding the
> product you can use our StackOverflow forum to raise them as well.
>
>- Developer List: dev@wso2.org
>- Architecture List: architect...@wso2.org
>- User Forum: StackOverflow
>
>
> Reporting Issues
> We encourage you to report issues, improvements, and feature requests
> regarding WSO2 Identity Server through our public WSO2 Identity Server
> JIRA .
>
> ~ The WSO2 Identity and Access Management Team ~
>
> *Jayanga Kaushalya*
> Software Engineer
> Mobile: +94777860160 <+94%2077%20786%200160>
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Charon] Charon 3 missing password setter method for User

[Johann Nallathamby]

Any SCIM experts who can answer this query?

Regards,
Johann.

On Thu, Nov 9, 2017 at 2:35 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> *[+IAM Team]*
>
> On Thu, Nov 9, 2017 at 2:11 PM, Isuranga Perera <isurangamper...@gmail.com
> > wrote:
>
>> Hi All,
>>
>> Even though Charon 2 User class has setter methods for password and other
>> attributes Charon 3 doesn't provide most of those setter methods. So is
>> there any other way I can set the password and other attributes without
>> editing the encoded user object. Appreciate any help.
>>
>> Best Regards
>> Isuranga Perera
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [Charon] Charon 3 missing password setter method for User

[Johann Nallathamby]

*[+IAM Team]*

On Thu, Nov 9, 2017 at 2:11 PM, Isuranga Perera 
wrote:

> Hi All,
>
> Even though Charon 2 User class has setter methods for password and other
> attributes Charon 3 doesn't provide most of those setter methods. So is
> there any other way I can set the password and other attributes without
> editing the encoded user object. Appreciate any help.
>
> Best Regards
> Isuranga Perera
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] How to configure SCIM to generate an email when ask password option is provided for user creation

[Johann Nallathamby]

Again I think we've missed the point to explain why we need to define
claims to get this feature working. If that was explained, naturally a user
will think when he is sending a request using SCIM APIs whether he has
included these claims also. And then he will follow that by thinking if he
has done the claim mappings properly; if he understands how IS and claim
mappings work. Making him understand that is not part of this section; what
we can do here is, may be link to the section on claim management. This
will keep this section concise and clear. Because it won't scale if we go
to give instructions for every protocol/dialect we have. And I think in
another conversation we said we will remove anything related to APIs from
the deep dive pages and have it only in the developer section.

If you still think we may need more hand holding of the user then we can
have a tutorial section for this - "Identity Administration with SCIM".

Regards,
Johann.

On Fri, Nov 3, 2017 at 9:37 PM, Sathya Bandara  wrote:

> Hi Sashika,
>
> I guess the documentation is missing some configuration details. The
> askPassword and verifyEmail extension attributes should be configured in
> $SERVER_HOME/repository/conf/scim-schema-extension.config file in
> addition to the other extension attributes which are already defined there,
> as follows.
>
> {
> "attributeURI":"urn:scim:schemas:extension:wso2:1.0:
> wso2Extension.askPassword",
> "attributeName":"askPassword",
> "dataType":"boolean",
> "multiValued":"false",
> "multiValuedAttributeChildName":"null",
> "description":"The User's manager",
> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
> "readOnly":"false",
> "required":"false",
> "caseExact":"false",
> "subAttributes":"null"
> },
>
>
> {
> "attributeURI":"urn:scim:schemas:extension:wso2:1.0:
> wso2Extension.verifyEmail",
> "attributeName":"verifyEmail",
> "dataType":"boolean",
> "multiValued":"false",
> "multiValuedAttributeChildName":"null",
> "description":"The User's manager",
> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
> "readOnly":"false",
> "required":"false",
> "caseExact":"false",
> "subAttributes":"null"
> },
>
> These two attributes should be added to the list of subAttributes of the
> urn:scim:schemas:extension:wso2:1.0 entry which can be find at the end of
> the scim-schema-extension.config file as shown below.
>
> {
> "attributeURI":"urn:scim:schemas:extension:wso2:1.0",
> "attributeName":"wso2Extension",
> "dataType":"null",
> "multiValued":"false",
> "multiValuedAttributeChildName":"null",
> "description":"SCIM wso2 User Schema Extension",
> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
> "readOnly":"false",
> "required":"false",
> "caseExact":"false",
> "subAttributes":"employeeNumber costCenter organization division
> department manager askPassword verifyEmail"
> }
>
>
> Also The correct approach to create claim mappings for SCIM extension
> attributes is by configuring external claims for the default SCIM dialect
> (scim:schemas:core:1.0) and not by creating a separate dialect for the
> extension schema (scim:schemas:extension:wso2:1.0:wso2Extension). This is
> already identified in [1] and the relevant documents has been updated.
> Please refer Claim Mapping section in [2]. Also I will create a Doc JIRA to
> improve the documentation with necessary configuration details in [3].
>
>
> [1] https://wso2.org/jira/browse/DOCUMENTATION-4647
> [2] https://docs.wso2.com/display/IS530/Extensible+SCIM+User+
> Schemas+With+WSO2+Identity+Server
> [3] https://docs.wso2.com/display/IS530/Creating+Users+using+
> the+Ask+Password+Option
>
> Thanks,
> Sathya
>
>
>
> On Fri, Nov 3, 2017 at 2:46 PM, Sashika Wijesinghe 
> wrote:
>
>> Hi All,
>>
>> I want to create users with ask password option using SCIM 1.1. I have
>> configured the server as documented in [1].
>>
>> The below curl command is used to create the user. After executing the
>> curl command, the user created successfully but did not receive any email
>> notification for the given email address. This works when I created a user
>> from the management console and SOAP admin service.
>>
>> Do we need any further configurations to get this done with SCIM 1.1?
>>
>> curl -v -k --user admin:admin --data "{"schemas":[],"userName":"nee
>> ls","password":"password","wso2Extension":{"askPassword":"
>> true"},"emails":"sash...@wso2.com"}" --header
>> "Content-Type:application/json" https://localhost:9444/wso2/scim/Users
>>
>> [1] https://docs.wso2.com/display/IS530/Creating+Users+using
>> +the+Ask+Password+Option
>>
>> Thanks
>> Sashika
>>
>>
>>
>>
>> --
>>
>> *Sashika WijesingheSoftware Engineer - QA Team*
>> Mobile : +94 (0) 774537487
>> sash...@wso2.com
>>
>
>
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.

Re: [Dev] How to configure SCIM to generate an email when ask password option is provided for user creation

[Johann Nallathamby]

On Sat, Nov 4, 2017 at 12:27 PM, Sashika Wijesinghe 
wrote:

> Hi Sathya,
>
> Thanks for the configuration requirements provided above. It helps to
> resolve the issue.
>
> According to the current implementation, since we are mapping the claims
> for SCIM extension isn't it better to have the claim configurations mapped
> in the scim-schema-extension.config itself when we bundle the pack rather
> than asking the user to add these configurations manually?
>

+1. I think we have discussed this several other mail threads as well;
can't seem to find them now. Basically we need to have default mappings for
all the identity claims we use in IS such as ask password, email
verification, etc., including for OOTB connectors, and have OOTB mappings
to these identity claims in OIDC, SCIM and other standard dialects we use
in the inbound side (we can omit the Identity Provider dialects like
Facebook, LinkedIn, etc. which is only used in outbound side).

[1] "[IAM] Pre-configure "Identity Claim" mappings for widely used Local
Authenticators"

Regards,
Johann.


>
> Thanks
> Sashika
>
>
>
> On Fri, Nov 3, 2017 at 9:37 PM, Sathya Bandara  wrote:
>
>> Hi Sashika,
>>
>> I guess the documentation is missing some configuration details. The
>> askPassword and verifyEmail extension attributes should be configured in
>> $SERVER_HOME/repository/conf/scim-schema-extension.config file in
>> addition to the other extension attributes which are already defined there,
>> as follows.
>>
>> {
>> "attributeURI":"urn:scim:schemas:extension:wso2:1.0:wso2Exte
>> nsion.askPassword",
>> "attributeName":"askPassword",
>> "dataType":"boolean",
>> "multiValued":"false",
>> "multiValuedAttributeChildName":"null",
>> "description":"The User's manager",
>> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
>> "readOnly":"false",
>> "required":"false",
>> "caseExact":"false",
>> "subAttributes":"null"
>> },
>>
>>
>> {
>> "attributeURI":"urn:scim:schemas:extension:wso2:1.0:wso2Exte
>> nsion.verifyEmail",
>> "attributeName":"verifyEmail",
>> "dataType":"boolean",
>> "multiValued":"false",
>> "multiValuedAttributeChildName":"null",
>> "description":"The User's manager",
>> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
>> "readOnly":"false",
>> "required":"false",
>> "caseExact":"false",
>> "subAttributes":"null"
>> },
>>
>> These two attributes should be added to the list of subAttributes of the
>> urn:scim:schemas:extension:wso2:1.0 entry which can be find at the end
>> of the scim-schema-extension.config file as shown below.
>>
>> {
>> "attributeURI":"urn:scim:schemas:extension:wso2:1.0",
>> "attributeName":"wso2Extension",
>> "dataType":"null",
>> "multiValued":"false",
>> "multiValuedAttributeChildName":"null",
>> "description":"SCIM wso2 User Schema Extension",
>> "schemaURI":"urn:scim:schemas:extension:wso2:1.0",
>> "readOnly":"false",
>> "required":"false",
>> "caseExact":"false",
>> "subAttributes":"employeeNumber costCenter organization division
>> department manager askPassword verifyEmail"
>> }
>>
>>
>> Also The correct approach to create claim mappings for SCIM extension
>> attributes is by configuring external claims for the default SCIM dialect
>> (scim:schemas:core:1.0) and not by creating a separate dialect for the
>> extension schema (scim:schemas:extension:wso2:1.0:wso2Extension). This
>> is already identified in [1] and the relevant documents has been updated.
>> Please refer Claim Mapping section in [2]. Also I will create a Doc JIRA to
>> improve the documentation with necessary configuration details in [3].
>>
>>
>> [1] https://wso2.org/jira/browse/DOCUMENTATION-4647
>> [2] https://docs.wso2.com/display/IS530/Extensible+SCIM+User+Sch
>> emas+With+WSO2+Identity+Server
>> [3] https://docs.wso2.com/display/IS530/Creating+Users+using+the
>> +Ask+Password+Option
>>
>> Thanks,
>> Sathya
>>
>>
>>
>> On Fri, Nov 3, 2017 at 2:46 PM, Sashika Wijesinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I want to create users with ask password option using SCIM 1.1. I have
>>> configured the server as documented in [1].
>>>
>>> The below curl command is used to create the user. After executing the
>>> curl command, the user created successfully but did not receive any email
>>> notification for the given email address. This works when I created a user
>>> from the management console and SOAP admin service.
>>>
>>> Do we need any further configurations to get this done with SCIM 1.1?
>>>
>>> curl -v -k --user admin:admin --data "{"schemas":[],"userName":"nee
>>> ls","password":"password","wso2Extension":{"askPassword":"tr
>>> ue"},"emails":"sash...@wso2.com"}" --header
>>> "Content-Type:application/json" https://localhost:9444/wso2/scim/Users
>>>
>>> [1] https://docs.wso2.com/display/IS530/Creating+Users+using
>>> +the+Ask+Password+Option
>>>
>>> Thanks
>>> Sashika
>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Sashika WijesingheSoftware Engineer - QA Team*
>>> Mobile : +94 (0) 774537487
>>> sash...@wso2.com
>>>
>>

Re: [Dev] How to configure the IS Dashboard for a IS cluster fronted by Nginx

[Johann Nallathamby]

Hi Sashika,

Please follow [1] to get your scenario working.

[1] http://isurad.blogspot.com/2016/02/wso2-identity-server-
510-behind_18.html

*@Samuel*:
This has been already discussed in [1], and have two L1 Documentation JIRAs
[2,3]. [1] has been created before IS 5.2.0 release. I thought we follow
the practice of closing out all the L1 documentation JIRAs before release.
If we haven't been able to do it previously, we have to do it going forward.

[1] "[Documentation][IS] Clustering documentation needs an update." in
documentat...@wso2.com
[2] https://wso2.org/jira/browse/DOCUMENTATION-1924
[3] https://wso2.org/jira/browse/DOCUMENTATION-4746


Regards,
Johann.

On Thu, Oct 26, 2017 at 11:32 AM, Sashika Wijesinghe 
wrote:

> Hi Ashen,
>
> We have already configured the proxy port in the catalina-server.xml.
>
> Regards,
> Sashika
>
>
>
> On Thu, Oct 26, 2017 at 11:19 AM, Ashen Weerathunga 
> wrote:
>
>> Hi Sashika,
>>
>> Have you added the proxy port 443 for https connector in
>> *catalina-server.xml*?
>> That config needs to be there for the dashboard.
>>
>> Go to /repository/conf/tomcat/catalina-server.xml and add the
>> proxy port 443 as below.
>>
>> >   port="9443"
>>   proxyPort="443"
>>
>>
>> Thanks,
>> Ashen
>>
>> On Thu, Oct 26, 2017 at 10:56 AM, Sashika Wijesinghe 
>> wrote:
>>
>>> Hi Ashen,
>>>
>>> The IS clustering guide you pointed out does not contain any information
>>> to configure the IS dashboard in a cluster setup.
>>>
>>> In my scenario, I can log in to the management console successfully but
>>> the issue occurs when login to the IS dashboard. Could this be due to any
>>> missing configuration?
>>>
>>> Thanks
>>> Sashika
>>>
>>> On Thu, Oct 26, 2017 at 12:35 AM, Ashen Weerathunga 
>>> wrote:
>>>
 Hi Sashika,

 Can you check with IS 5.4.0 Clustered guide [1].
 I guess it has the information you need.

 [1] https://docs.wso2.com/display/IS540/Clustered+Deployment

 Thanks,
 Ashen

 On Wed, Oct 25, 2017 at 5:34 PM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Oct 24, 2017 at 5:41 PM, Sashika Wijesinghe 
> wrote:
>
>> Hi All,
>>
>> We have configured two IS nodes fronted by Nginx and the site.json
>> with server host details as below.
>>
>> {
>> "proxy" : {
>> "proxyHost" : "is.dev.wso2.org",
>> "proxyHTTPSPort" : "443",
>> "proxyContextPath" : "",
>> "servicePath" : "/services"
>> }
>> }
>>
>>
>> When I log in to the Management Console with the admin user,
>> authentication was successful but failed to login to the IS Dashboard 
>> with
>> admin user or any user who have permission to the IS Dashboard login.
>>
>> Following is the authentication exception logged in the terminal.
>>
>> Any suggestion to solve this issue is highly appreciated.
>>
>
> Don't we have a doc on configuring WSO2IS with Nginx  ?
>
> Thanks,
> Asela.
>
>>
>>
>> TID: [-1234] [] [2017-10-24 05:28:50,683] ERROR
>> {org.wso2.carbon.identity.authenticator.saml2.sso.SAML2SSOAuthenticator}
>> -  Authentication Request is rejected. SAMLResponse AudienceRestriction
>> validation failed.
>> TID: [-1] [] [2017-10-24 05:28:50,683]  WARN
>> {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} -
>>  Failed Administrator login attempt 'admin@carbon.super[-1]' at
>> [2017-10-24 05:28:50,683+]
>> TID: [-1234] [] [2017-10-24 05:28:50,751]  WARN
>> {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler}
>> -  Illegal access attempt at [2017-10-24 05:28:50,0751] from IP address
>> 192.168.57.251 while trying to authenticate access to service
>> WorkflowImplAdminService
>>
>> TID: [-1] [] [2017-10-24 05:28:49,939]  INFO
>> {org.wso2.carbon.core.clustering.hazelcast.HazelcastClusterMessageListener}
>> -  Received ClusteringMessage: org.wso2.carbon.identity.entit
>> lement.PolicyStatusClusterMessage@d47e9b84
>> TID: [-1234] [] [2017-10-24 05:28:50,778]  INFO {
>> org.apache.axis2.transport.http.HTTPSender} -  Unable to sendViaPost
>> to url[https://is.dev.wso2.org/services/WorkflowImplAdminServic
>> e.WorkflowImplAdminServiceHttpsSoap11Endpoint/]
>> org.apache.axis2.AxisFault: Transport error: 401 Error: Unauthorized
>> at org.apache.axis2.transport.http.HTTPSender.handleResponse(HT
>> TPSender.java:326)
>> at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPS
>> ender.java:196)
>> at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.j
>> ava:77)
>> at org.apache.axis2.transport.http.CommonsHTTPTransportSender.w
>> riteMessageWithCommons(CommonsHTTPTransportSender.java:451)
>> at 

Re: [Dev] Can we use placeholders for host name and port in IS connector configurations

[Johann Nallathamby]

Hi Malithi,

+1 to use placeholders like we do in IS. This prevents the user from
falling into trouble and I can say that the IS user experience after we
provided placeholder support in IS 5.1.0 has been much better.

Regards,
Johann.

On Tue, Oct 24, 2017 at 12:09 AM, Malithi Edirisinghe 
wrote:

> Hi Team,
>
> I noted that we need to specifically configure server hostname and port
> while configuring some IS connectors like SMSOTP and TOTP. Can't we use
> placeholders instead?
>
> Meanwhile *@IAMTeam*, if we are shipping connectors OOTB, I think we need
> to have updated configs as well. Both, SMSOTP and TOTP are shipped with the
> product but respective connector configurations are either outdated or not
> to be found at all.
>
> Thanks,
> Malithi.
>
> --
>
> *Malithi Edirisinghe*
> Associate Technical Lead
> WSO2 Inc.
>
> Mobile : +94 (0) 718176807
> malit...@wso2.com
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] AuthenticationAdmin is not configured as an admin service

[Johann Nallathamby]

By definition admin services are services that require authentication and
authorization. This is the parameter you find in the services.xml of the
service. If that is set to false then it is not an admin service.
AuthenticationAdmin is the service to do authentication. So obviously you
can't have authentication and authorization for it.

However it is also common parlance to refer to services that are shipped
with the product for management console usage, as administrative services,
which should not be confused with admin service parameter in services.xml.

Therefore although AuthenticationAdmin service can be called an
administrative service because we use it primarily to authenticate users to
carbon management console, and for other application authentication we have
SCIM /me endpoint and OIDC /userinfo, technically it is not an admin
service in services.xml terminology because it doesn't require
authentication and authorization.

Hope that clarifies.

Regards,
Johann.

On Tue, Oct 24, 2017 at 11:57 AM, Nuwandi Wickramasinghe 
wrote:

> Hi all,
>
> Noticed $subject while reviewing [1]. In services.xml
> for AuthenticationAdmin, adminservice parameter is set to false ([2]). Any
> specific reason for this?
>
> However in doc link [3] (step 8th point under *Discovering the admin
> services*), we have given AuthenticationAdmin as an example for an admin
> service. If we are not keeping AuthenticationAdmin as an admin service,
> need to change the document.
>
> [1] https://wso2.org/jira/browse/IDENTITY-6782
> [2] https://github.com/wso2/carbon-kernel/blob/ddf7da2559d5c
> c709ed14965f04dd0e00ca51c0d/core/org.wso2.carbon.core.
> services/src/main/resources/META-INF/services.xml#L49-L49
> [3] https://docs.wso2.com/display/IS530/Calling+Admin+Services
>
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Pre-configure "Identity Claim" mappings for widely used Local Authenticators

[Johann Nallathamby]

IAM Devs,

Currently to setup some of the local authenticators it's a hassle to copy
paste the claim URIs from the documentation and configure attribute
mappings. It will be much easier if these mappings are available OOTB, and
mapped to meaningful attributes. Also if we have this pre-configured in
claim-config.xml we don't need to repeat for each tenant.

Widely used local authenticators are - TOTP, SMS-OTP, Email-OTP, X509 and
Password Policy authenticator.

Thoughts? Any other authenticator to add to the above list?

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Making it easy to setup dialects for well known Identity Providers for existing IS deployments

[Johann Nallathamby]

On Mon, Oct 16, 2017 at 1:28 AM, Johann Nallathamby <joh...@wso2.com> wrote:

> IAM Devs,
>
> I think for all the well know Identity Providers (including social
> authentication sites) we have the practice of defining a claim dialect in
> claim management to do mapping easily without having to duplicate for each
> IdP in each tenant. For the OOTB connectors we may be shipping these
> mappings in claim-config.xml. But how are we expecting the users to do this
> for the connectors in the store? Have they got to do it manually by looking
> at the documentation for the super tenant and each tenant created so far?
>
> How about if we can do this one time setup task in the connector itself
> for super tenant and all existing tenants? Basically if we can define the
> new dialect in claim-config.xml and restart the server, when the
> getClaimDialectURI() method of each connector is invoked we can check for
> the existence of the dialect in the super tenant and each of the tenants
> created so far and execute a logic to read and store the new dialect once
> after startup. This will cause the first request to the connector to be
> slower. I was thinking of a init() method that may be called on server
> startup but I don't think we have one for ApplicationAuthenticator API.
>

In fact we can even do this in each of the connector active() method also
right? This will make sure the first request isn't slowing down.


>
> This logic can be written in the common utility bundle of all the
> extensions and shared across the connectors.
>
> Thoughts?
>
> Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

[Dev] Making it easy to setup dialects for well known Identity Providers for existing IS deployments

[Johann Nallathamby]

IAM Devs,

I think for all the well know Identity Providers (including social
authentication sites) we have the practice of defining a claim dialect in
claim management to do mapping easily without having to duplicate for each
IdP in each tenant. For the OOTB connectors we may be shipping these
mappings in claim-config.xml. But how are we expecting the users to do this
for the connectors in the store? Have they got to do it manually by looking
at the documentation for the super tenant and each tenant created so far?

How about if we can do this one time setup task in the connector itself for
super tenant and all existing tenants? Basically if we can define the new
dialect in claim-config.xml and restart the server, when the
getClaimDialectURI() method of each connector is invoked we can check for
the existence of the dialect in the super tenant and each of the tenants
created so far and execute a logic to read and store the new dialect once
after startup. This will cause the first request to the connector to be
slower. I was thinking of a init() method that may be called on server
startup but I don't think we have one for ApplicationAuthenticator API.

This logic can be written in the common utility bundle of all the
extensions and shared across the connectors.

Thoughts?

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Shall we remove InfoRecoverySample from product-is?

[Johann Nallathamby]

SOAP APIs are supported for backward compatibility of the product in a
minor version. However I don't think users looking at samples are users who
are migrating from IS 5.2.0 to 5.3.0 and have been using identity
management SOAP APIs in IS 5.2.0. Users who come to see samples are
absolutely new users. So IMO, it's fine to remove the old samples from IS
5.4.0 branch.

Moreover, in a meeting with documentation team we decided to remove the old
identity management content from IS 5.3.0 documentation and link to the
5.2.0 documentation to avoid confusion to the users. So in that case the
sample documentation also will be removed [1]. So another reason why the
old sample also could be removed. Only issue may be if we fix the old
sample specifically for IS 5.3.0, but I don't think that can happen in
anyway.

There is a public JIRA reported on the sample for old identity management
implementation [2]. I don't know if this issue is a documentation issue
[1], or code issue. However, since we have deprecated the component and
removing relevant content from IS 5.3.0 docs, we don't need to spend time
fixing these issues in public branch IMHO.

[1]
https://docs.wso2.com/display/IS530/Configuring+Sample+Application+for+Identity+Management
[2] https://wso2.org/jira/browse/IDENTITY-6712

Regards,
Johann.

On Mon, Sep 4, 2017 at 9:21 PM, Isura Karunaratne <is...@wso2.com> wrote:

>
> On Mon, Sep 4, 2017 at 9:00 PM Pulasthi Mahawithana <pulast...@wso2.com>
> wrote:
>
>> Hi Johann,
>>
>> Since we are still keeping the deprecated SOAP APIs we'll keep the sample
>> also till the next major version.
>>
> Yes. +1 to keep the sample since we support SOAP apis too.
>

> Thanks
> Isura
>
>>
>> On Mon, Sep 4, 2017 at 8:42 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> If we are going to keep it in product-is we need to maintain
>>> compatibility with latest APIs. But I think we have even resolved some
>>> public JIRAs mentioning the fact that we now support this in identity-mgt
>>> webapp. So we don't need a separate sample for this.
>>>
>>> So, I think we can do $subject.
>>>
>>> Regards,
>>> Johann.
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>> Blog: https://medium.com/@pulasthi7/
>>
>> <https://wso2.com/signature>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
> --
>
> *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/
>
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] Please review and merge PR

[Johann Nallathamby]

Hi Isuranga,

First of all thank you for your contribution to WSO2 Identity Server.

However, can you please follow the following protocol in order to get your
PRs merged faster.

1. Create one JIRA per issue. Make sure you give the description clearly.
Add the PRs related to the issue in the JIRA.
2. Send a mail to dev with the subject indicating the issue you are fixing
(prefix with "[IAM]" is recommended).
3. Describe the problem (can be the same as description of the JIRA).
4. Give the references to the JIRA and PRs.
5. Request to review and merge.

In the above mail there is no mention of the issue neither in the subject
nor body. This won't get the attention of the required individuals (IAM)
since the dev mailing list is a global mailing list for all development
queries in WSO2.

Also there are two separate issues in this mail. Always stick to one mail
per issue so the discussion is focussed on one issue only. You have already
sent a mail for the balana initialization issue [1]. You can add relevant
JIRA and PR to that. Please send a separate mail for the custom function
issue.

Thanks again for the contribution.

[1] "[Dev][IS][XACML] Introducing a Custom functionId"

Regards,
Johann.

On Thu, Oct 12, 2017 at 10:52 AM, Isuranga Perera  wrote:

> Can you please review and merge PR[1] and PR[2].
>
> [1] https://github.com/wso2/balana/pull/75
> [2] https://github.com/wso2/carbon-identity-framework/pull/1112
>
> Best Regards
> Isuranga Perera
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Fwd: SCIM enable in user store level.

[Johann Nallathamby]

IAM team can we change the default value here for IS 5.4.0? I think we
discussed the same during IS 5.3.0 release also but somehow have missed to
change it for JDBCUserStoreManager.

Regards,
Johann.

-- Forwarded message --
From: Johann Nallathamby <joh...@wso2.com>
Date: Tue, Oct 10, 2017 at 6:58 AM
Subject: Re: SCIM enable in user store level.
To: Harsha Thirimanna <hars...@wso2.com>
Cc: Sherene Mahanama <sher...@wso2.com>, Maduranga Siriwardena <
madura...@wso2.com>, WSO2 Documentation <documentat...@wso2.com>




On Tue, Oct 10, 2017 at 12:56 AM, Harsha Thirimanna <hars...@wso2.com>
wrote:

> Hi Maduranga,
>
> There is condition in code as follows to before the SCIM operation.
>
> userStoreManager.isSCIMEnabled()
>
> Property is "" in user-mgt.xml
>
> We have to mention this in SCIM doc as well, because for JDBC user stores,
> this is disable by default.
>

Why is this disabled by default? We should enabled this for all the user
stores. And regardless of whether we have enabled/disabled we still need to
explain about this property in SCIM docs.

Regards,
Johann.


>
> thanks
>
> *Harsha Thirimanna*
> *Associate Tech Lead | WSO2*
>
> Email: hars...@wso2.com
> Mob: +94715186770 <+94%2071%20518%206770>
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/ha
> rsha-thirimanna/10/ab8/122
> <http://wso2.com/signature>
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [IS][XACML] Introducing a Custom functionId

[Johann Nallathamby]

Will someone be able to shed some light on this issue sooner than later,
because Isuranga is trying to contribute a useful feature to WSO2 IS, which
is discussed in [1].

[1] [IAM] Restful API to Evaluate Permission Tree in IS

Regards,
Johann.

On Thu, Oct 5, 2017 at 7:22 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> *[+Asela, IAM Team]*
>
> On Thu, Oct 5, 2017 at 7:20 PM, Isuranga Perera <isurangamper...@gmail.com
> > wrote:
>
>> Hi All,
>>
>> I'm trying to introduce a new XACML function in IS 5.3. This is the
>> procedure I followed so far.
>>
>>- Create the new class by extending the *FunctionBase* abstract class.
>>- Created a jar file and copied it into
>>*/repository/components/lib* directory
>>- Created "balana-config.xml" file with the following content and
>>copied it into */repository/conf/security*
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> *> defaultAttributeFactory="attr" defaultCombiningAlgFactory="comb"
>> defaultFunctionFactory="func">  > class="org.wso2.balana.finder.impl.CurrentEnvModule"/>
>>  > class="org.wso2.balana.finder.impl.SelectorModule"/>  > name="attr" useStandardDatatypes="true"/> > useStandardFunctions="true">  > class="org.wso2.xacml.permissions.PermissionEvalFunction"/>
>>> useStandardAlgorithms="true" />*
>>
>>- Set property
>>
>>*PDP.Balana.Config.Enable=true *in
>>*/repository/conf/identity/entitlement.properties*
>>
>> But when I tried to use that functionId in a policy it throws an
>> Exception saying functionId doesn't exist. It seems even my config file is
>> not parsed.
>> Appreciate any help.
>>
>> Best Regards,
>> Isuranga Perera
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [IS][XACML] Introducing a Custom functionId

[Johann Nallathamby]

*[+Asela, IAM Team]*

On Thu, Oct 5, 2017 at 7:20 PM, Isuranga Perera 
wrote:

> Hi All,
>
> I'm trying to introduce a new XACML function in IS 5.3. This is the
> procedure I followed so far.
>
>- Create the new class by extending the *FunctionBase* abstract class.
>- Created a jar file and copied it into
>*/repository/components/lib* directory
>- Created "balana-config.xml" file with the following content and
>copied it into */repository/conf/security*
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> * defaultAttributeFactory="attr" defaultCombiningAlgFactory="comb"
> defaultFunctionFactory="func">   class="org.wso2.balana.finder.impl.CurrentEnvModule"/>
>   class="org.wso2.balana.finder.impl.SelectorModule"/>   name="attr" useStandardDatatypes="true"/>  useStandardFunctions="true">   class="org.wso2.xacml.permissions.PermissionEvalFunction"/>
> useStandardAlgorithms="true" />*
>
>- Set property
>
>*PDP.Balana.Config.Enable=true *in
>*/repository/conf/identity/entitlement.properties*
>
> But when I tried to use that functionId in a policy it throws an Exception
> saying functionId doesn't exist. It seems even my config file is not parsed.
> Appreciate any help.
>
> Best Regards,
> Isuranga Perera
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] SCIM 2.0 as default in IS 5.4.0

[Johann Nallathamby]

Any thoughts on the above idea or did we fix it in a different way?

On Sat, Sep 23, 2017 at 9:46 AM, Johann Nallathamby <joh...@wso2.com> wrote:

> See if this idea would work?
>
> We currently set a threadlocal variable inside the SCIM endpoint
> component, to identify the SCIM service provider inside some of our
> implementations. Can we improve this variable value to also identify the
> SCIM version? This way the relevant listeners will check for the correct
> version and only execute.
>
> For management console operations we won't have a threadlocal set. In that
> case one of the listeners (ideally SCIM2) will execute and do the necessary
> changes to the user store, so that thereafter even if we do calls using
> SCIM 1.1. it should work without a problem.
>
> This way we are not coupling the listeners, each version works
> independently, and management console will depend on latest version. Even
> if tomorrow SCIM 3.0 comes out we don't need to change existing code :)
>
> Anyone see any issue with this approach? Am I missing anything?
>
> Regards,
> Johann.
>
> On Mon, Sep 18, 2017 at 11:04 AM, Pulasthi Mahawithana <pulast...@wso2.com
> > wrote:
>
>> Hi Gayan,
>>
>> On Mon, Sep 18, 2017 at 10:43 AM, Gayan Gunawardana <ga...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 18, 2017 at 10:19 AM, Prabath Siriwardena <prab...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Sep 17, 2017 at 9:42 PM, Gayan Gunawardana <ga...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 18, 2017 at 8:29 AM, Darshana Gunawardana <
>>>>> darsh...@wso2.com> wrote:
>>>>>
>>>>>> Hi Prabath,
>>>>>>
>>>>>> We do have two endpoints for SCIM 1.1 & SCIM 2. But there are some
>>>>>> listeners we need to enable in order to populated relevant metadata such 
>>>>>> as
>>>>>> ID, Created\Modified dates against the correct URI specified by the each
>>>>>> specification.
>>>>>>
>>>>>> Given that, different clients may use different protocol of they
>>>>>> already support, we should have ability to have both protocols working
>>>>>> simultaneously.
>>>>>>
>>>>> According to this even single client can use SCIM 1.1 and 2.0
>>>>> simultaneously right ?
>>>>> Yes so ideally it should work but in practice it will bring some
>>>>> complexities. We have to test use-cases like creating user with SCIM 1.1
>>>>> and updating with SCIM 2.0.
>>>>> IMO we should support only one protocol at a time but not both.
>>>>>
>>>>
>>>> Can we please identify those complexities...?
>>>>
>>>> We cannot terminate support for SCIM 1.1 - both have to co-exist for
>>>> few releases till we deprecate SCIM 1.1. If both cannot co-exist then we
>>>> need to review our design...
>>>>
>>> What I am suggesting is not to terminate support for SCIM 1.1 but at a
>>> time enable only.
>>> Enable SCIM 1.1 as default option. If client applications work with SCIM
>>> 1.1 they can continue. If client applications want to work with SCIM 2.0 we
>>> should be able to enable SCIM 2.0 by disabling SCIM 1.1 from
>>> configurations.
>>>
>>
>> What I initially suggested was the other way around. That is having SCIM
>> 2 as default and make SCIM 1.1 to enable with a config change. The reason
>> is, for any new users, they can use the newer standard OOTB without any
>> config changes. And for existing users who are using SCIM 1.1 clients will
>> anyway need to migrate to 5.4.0. During the migration, we keep the existing
>> configuration. So for them SCIM 1.1 will be enabled by default after the
>> migration process (They may switch later if needed).
>>
>> Anyway, as Darshana mentioned, We'll look for the possibility of having
>> both of them enabled at once.
>>
>>>
>>>> Thanks & regards,
>>>> -Prabath
>>>>
>>>>
>>>>
>>>>>
>>>>>> Created: https://wso2.org/jira/browse/IDENTITY-6458 to track this.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> On Mon, Sep 18, 2017 at 8:11 AM, Darshana Gunawardana <
>>>>>> darsh...@wso2.com> wrote:
>>>>

[Dev] Some clarifications regarding public JIRA resolution

[Johann Nallathamby]

1. I can see new states Done/Not Done. When do we use them? For
improvements or tasks?

2. JIRAs filtered here

don't have resolution state as "Fixed" nor "Done", but have "Fixed Version"
as 5.4.0. I don't think it right to set a "Fixed Version" for them. Can we
remove them?

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Fwd: [Carbon-jira] [jira] (IDENTITY-6330) [IS]When configured secondary jdbc userstore canot login with the secondary userstore user

[Johann Nallathamby]

1. Can someone explain the reason for the issue and relevance of the fix to
the issue reported here?

I can understand the issue here. I also assume I understand the reason for
the issue. But better someone explains. What I don't seem to understand is
the relevance of the fix here. It seems to me that the
"AuthenticationPolicy.CheckAccountExist" property was not used at all in
the new implementation. Now it's been put to use. I certainly don't think
not using this property is the reason for the issue. So I don't get the fix
done here.

2. Why do we have a private method *"isUserExistsInDomain"*? It doesn't
seem to do anything useful.

3. Seems we have introduced a new property to identity.xml
*"AuthenticationPolicy.CheckAccountExist".* Are we not thinking of adding
this to Resident IdP UI to control at a tenant level?

*Authentication.Policy.Check.Account.Exist* in the old
identity-mgt.properties file was there to control the level of details that
needs to be revealed to the users regarding authentication failure. I.e. we
gave a configuration to control whether the user should see a generic
authentication failure message, or s/he should see failure with reason such
as invalid username or invalid password.

Seems this property has been missed in the new implementation and now being
added.

4. Why is the new element uncommented by default which is inconsistent with
all other identity-mgt elements in identity.xml? Can we have a default
value and comment it out?

5. Is this code consistent with other handlers such as *AccountLockHandler*
and *AccountDisableHandler*?

Regards,
Johann.

-- Forwarded message --
From: Denuwanthi De Silva (JIRA) 
Date: Thu, Aug 31, 2017 at 10:09 AM
Subject: [Carbon-jira] [jira] (IDENTITY-6330) [IS]When configured secondary
jdbc userstore canot login with the secondary userstore user
To: carbon-j...@wso2.org


Denuwanthi De Silva

*created* an issue

WSO2 Identity Server  / [image: Bug]
 IDENTITY-6330

[IS]When configured secondary jdbc userstore canot login with the secondary
userstore user 
Issue Type: [image: Bug] Bug
Assignee: Darshana Gunawardana

Created: 31/Aug/17 10:08 AM
Priority: [image: Normal] Normal
Reporter: Denuwanthi De Silva


1.create a user in SECONDARY oracle jdbc userstore.
2.try to login with that user
login fails.
ERROR
{org.wso2.carbon.core.services.authentication.AuthenticationAdmin}

- System error while Authenticating/Authorizing User : Error when handling
event : PRE_AUTHENTICATION
3.If login with domain ex(SECONDARY/user1) log in without issue.
[image: Add Comment]
 Add Comment


This message was sent by Atlassian JIRA (v7.2.2#72004-sha1:9d51328)
[image: Atlassian logo]

___
Carbon-jira mailing list
carbon-j...@wso2.org
https://wso2.org/cgi-bin/mailman/listinfo/carbon-jira




-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] What is the correct behavior when user store selected from Inbound Provisioning Configuration

[Johann Nallathamby]

IMO, returning the username with userstore domain in the response may be
seen as an unwanted sensitive information leak in this setup. Ideally in
these kind of scenarios expectation is service provider doesn't need to
know the user store domain name where his users are created. Therefore they
can provision without the user store domain in the username. And response
also will return the username only.

If they send a invalid or unauthorized domain I think we have to return
back and unauthorized error saying "Not authorized to provision to the
domain".

But then again I am not sure if the service provider can carry out all SCIM
operations without knowing the domain name.

Regards,
Johann.

On Tue, Sep 19, 2017 at 12:40 AM, Darshana Gunawardana 
wrote:

> There is no hard rule to specify which one should be the correct approach
> in this case. Since there is always room to override this setting using
> specific SP's configuration, I think current approach is ok.
>
> Thanks,
>
> On Tue, Sep 19, 2017 at 12:30 AM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Tue, Sep 19, 2017 at 12:13 AM, Darshana Gunawardana > > wrote:
>>
>>> Since we returning the correct username in the response, its should be
>>> ok. This is a configuration issue if the client is expecting otherway.
>>>
>> I think it is better if there is a way to inform client application about
>> configuration issue. There is a possibility that SCIM consumers may not
>> look into admin console configurations at all. Also there is a high
>> possibility to client application to depend on only http response code.
>>
>>>
>>> Thanks,
>>>
>>> On Tue, Sep 19, 2017 at 12:10 AM, Gayan Gunawardana 
>>> wrote:
>>>


 On Mon, Sep 18, 2017 at 11:42 PM, Darshana Gunawardana <
 darsh...@wso2.com> wrote:

> Ok, now you asked the real question :)
>
> Yes I agree with the expected results you mentioned for all three
> cases. I have checked this behaviour on a latest pack[1][2] and it only
> provision user to specified userstore in the SP configuration in the case 
> 3
> which is a reasonable behariour. (I'm using locally built 5.4.0-SNAPSHOT
> version, which is slightly newer than 5.4.0-alpha2)
>
> What is the pack that you have tried?
>
 I have used 5.4.0-alpha2 and your observation is correct i haven't get
 expected result due to some wrong configurations.
 We have to think about case 03 carefully because client application may
 understand as provisioning is successful but it may not be the intended
 user store.

>
> [1]
> Sample Request:
> POST /wso2/scim/Users HTTP/1.1
> Host: localhost:9443
> Content-Type: application/json
> Authorization: Basic YWRtaW46YWRtaW4=
> Cache-Control: no-cache
> Postman-Token: a07e5cab-f4e9-52dd-d245-1b65552c5539
>
> {
>   "schemas": [
>
>   ],
>   "userName": "LDAP/darra...@wso2.com",
>   "password": "darray"
> }
>
> [2]
> Sample Response:
> {
> "meta": {
> "created": "2017-09-18T23:28:23",
> "location": "https://localhost:9443/wso2/s
> cim/Users/3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd",
> "lastModified": "2017-09-18T23:28:23"
> },
> "schemas": [
> "urn:scim:schemas:core:1.0"
> ],
> "id": "3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd",
> "userName": "H2/darra...@wso2.com"
> }
>
> Thanks,
>
>
> On Mon, Sep 18, 2017 at 11:00 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Mon, Sep 18, 2017 at 10:27 PM, Darshana Gunawardana <
>> darsh...@wso2.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 18, 2017 at 7:58 PM, Gayan Gunawardana 
>>> wrote:
>>>

 ​
 When user store selected from Inbound Provisioning Configuration
 should we allow to provision other user stores as well ?

>>>
>>> No.
>>>
>>>
 For an example if we selected "TEST" as user store from Inbound
 Provisioning Configuration, can we provision to PRIMARY user store as 
 well ?

>>>
>>> No.
>>>
>> Thanks Darshana but currently it works other way.
>>
>>>
>>> Given that you are already an expert on the provisioning area, I
>>> suppose you already knew the answers for above questions but you have a
>>> followup question in mind. May I know what that is? :)
>>>
>> I do not have specific follow up question :) just wanted to avoid
>> confusion of sending user store domain in request and selecting user 
>> store
>> domain from service provider.
>> case 01: Do not select user store domain from service provider and
>> sending user store domain in the request.
>> expectation: User store domain can be extracted from request and

Re: [Dev] SCIM 2.0 as default in IS 5.4.0

[Johann Nallathamby]

See if this idea would work?

We currently set a threadlocal variable inside the SCIM endpoint component,
to identify the SCIM service provider inside some of our implementations.
Can we improve this variable value to also identify the SCIM version? This
way the relevant listeners will check for the correct version and only
execute.

For management console operations we won't have a threadlocal set. In that
case one of the listeners (ideally SCIM2) will execute and do the necessary
changes to the user store, so that thereafter even if we do calls using
SCIM 1.1. it should work without a problem.

This way we are not coupling the listeners, each version works
independently, and management console will depend on latest version. Even
if tomorrow SCIM 3.0 comes out we don't need to change existing code :)

Anyone see any issue with this approach? Am I missing anything?

Regards,
Johann.

On Mon, Sep 18, 2017 at 11:04 AM, Pulasthi Mahawithana 
wrote:

> Hi Gayan,
>
> On Mon, Sep 18, 2017 at 10:43 AM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Mon, Sep 18, 2017 at 10:19 AM, Prabath Siriwardena 
>> wrote:
>>
>>>
>>>
>>> On Sun, Sep 17, 2017 at 9:42 PM, Gayan Gunawardana 
>>> wrote:
>>>


 On Mon, Sep 18, 2017 at 8:29 AM, Darshana Gunawardana <
 darsh...@wso2.com> wrote:

> Hi Prabath,
>
> We do have two endpoints for SCIM 1.1 & SCIM 2. But there are some
> listeners we need to enable in order to populated relevant metadata such 
> as
> ID, Created\Modified dates against the correct URI specified by the each
> specification.
>
> Given that, different clients may use different protocol of they
> already support, we should have ability to have both protocols working
> simultaneously.
>
 According to this even single client can use SCIM 1.1 and 2.0
 simultaneously right ?
 Yes so ideally it should work but in practice it will bring some
 complexities. We have to test use-cases like creating user with SCIM 1.1
 and updating with SCIM 2.0.
 IMO we should support only one protocol at a time but not both.

>>>
>>> Can we please identify those complexities...?
>>>
>>> We cannot terminate support for SCIM 1.1 - both have to co-exist for few
>>> releases till we deprecate SCIM 1.1. If both cannot co-exist then we need
>>> to review our design...
>>>
>> What I am suggesting is not to terminate support for SCIM 1.1 but at a
>> time enable only.
>> Enable SCIM 1.1 as default option. If client applications work with SCIM
>> 1.1 they can continue. If client applications want to work with SCIM 2.0 we
>> should be able to enable SCIM 2.0 by disabling SCIM 1.1 from
>> configurations.
>>
>
> What I initially suggested was the other way around. That is having SCIM 2
> as default and make SCIM 1.1 to enable with a config change. The reason is,
> for any new users, they can use the newer standard OOTB without any config
> changes. And for existing users who are using SCIM 1.1 clients will anyway
> need to migrate to 5.4.0. During the migration, we keep the existing
> configuration. So for them SCIM 1.1 will be enabled by default after the
> migration process (They may switch later if needed).
>
> Anyway, as Darshana mentioned, We'll look for the possibility of having
> both of them enabled at once.
>
>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>>

> Created: https://wso2.org/jira/browse/IDENTITY-6458 to track this.
>
> Thanks,
>
> On Mon, Sep 18, 2017 at 8:11 AM, Darshana Gunawardana <
> darsh...@wso2.com> wrote:
>
>> Hi Gayan,
>>
>> Due to the limitation we have in the user core level, we don't
>> support complex filtering, pagination, sorting. Refer [1] & [2].
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-prov
>> isioning-scim2/blob/v1.0.5/components/org.wso2.carbon.identi
>> ty.scim2.common/src/main/java/org/wso2/carbon/identity/scim2
>> /common/impl/SCIMUserManager.java#L834
>> [2] https://github.com/wso2-extensions/identity-inbound-prov
>> isioning-scim2/blob/v1.0.5/components/org.wso2.carbon.identi
>> ty.scim2.common/src/main/java/org/wso2/carbon/identity/scim2
>> /common/impl/SCIMUserManager.java#L793
>>
>> Thanks,
>>
>> On Mon, Sep 18, 2017 at 7:50 AM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 11, 2017 at 9:14 PM, Vindula Jayawardana <
>>> vindula...@cse.mrt.ac.lk> wrote:
>>>
 Hi,

 +1 for this as the global adoption of SCIM 2.0 is right on the
 track as Ishara has mentioned.

>>> @Vindula
>>> Do we support pagination, complex filters and bulk operation to
>>> resolve cyclic dependencies. As I know you have implemented these 
>>> features
>>> but there are some limitations because of C4 user core component. I am 
>>> not
>>> 

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

[Johann Nallathamby]

On Fri, Sep 1, 2017 at 10:36 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> In that case can we set a threadlocal variable in order to identify the
> SCIM version? Based on that the correct listener will execute and the other
> will not. Since SCIM1.1 listener will check for it's related threadlocal
> and SCIM2.0 listener it's related threadlocal there is not coupling between
> the two implementations. All the SCIM operations must set this threadlocal.
> I don't see any better solution for this problem.
>
> Regards,
> Johann.
>
> On Thu, Aug 31, 2017 at 6:54 PM, Sathya Bandara <sat...@wso2.com> wrote:
>
>>
>>
>> On Thu, Aug 31, 2017 at 2:18 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Hi Sathya,
>>>
>>> On Thu, Aug 31, 2017 at 12:29 PM, Sathya Bandara <sat...@wso2.com>
>>> wrote:
>>>
>>>> Hi Johann,
>>>>
>>>> IMO having two separate LDAP attributes for the same claims in both
>>>> SCIM1 and SCIM2 would be redundant and cause problems in maintaining user
>>>> attributes.
>>>>
>>>
>>> True. I didn't say this is the correct solution. I only mentioned it as
>>> a work around for someone who wants to use both without any conflicts until
>>> we find a alternative or deprecate SCIM 1.1 :)
>>>
>>>
>>>> If we need to have both listeners enabled at the time I would suggest
>>>> to use a common util method to generate IDs and do the mappings for the
>>>> claims that are common to both protocols.
>>>>
>>>
>>> Didn't get how this would help exactly. May be I am missing some context.
>>>
>>> However, after reading through your first reply again, now I have
>>> another question. Why do both the listeners get executed when adding a new
>>> user? I know they both will get triggered. But can't we look at the dialect
>>> URI at the top and skip the execution if it's not for that listener?
>>>
>>> When adding a user through normal approach(management console) when SCIM
>>> is enabled, it is not possible to figure out the dialect URI. In this case
>>> this will not work AFAIU.
>>>
>>
> Hmm..
>

True, that when adding through management console we can't identify the
SCIM version. But do we need to? If both the listeners are doing the same
change in the user store for SCIM1 and SCIM2, then either of the listeners
doing the change will be enough right?

I think this is getting a bit too complicated over mail. We can chat
offline if needed and come to a conclusion :)


>
>
>>
>>> Thanks,
>>> Sathya
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Sathya
>>>>
>>>> On Thu, Aug 31, 2017 at 11:37 AM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Will it work if we have two separate attributes for the problematic
>>>>> attributes like SCIM ID? If that works I guess that is one solution.
>>>>>
>>>>> Or we need to have one listener for both SCIM 1 and SCIM2. But don't
>>>>> think that's a good solution. Introduces direct coupling between two
>>>>> implementations.
>>>>>
>>>>> Regards,
>>>>> Johann.
>>>>>
>>>>> On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara <sat...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Thilina,
>>>>>>
>>>>>> If we enable both SCIM1 and SCIM2 listeners at the same time two
>>>>>> different SCIM IDs will be generated for the same user when adding a new
>>>>>> user through SCIM. Also both SCIM1 and SCIM2 claims are mapped to the 
>>>>>> same
>>>>>> LDAP user attributes. Even though both listeners get triggered only the
>>>>>> SCIM1 ID is mapped to the user ID attribute. But the SCIM2 user creation
>>>>>> response will contain the SCIM ID generated by SCIM2 listener.
>>>>>>
>>>>>> Thanks,
>>>>>> Sathya
>>>>>>
>>>>>> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal <thilina...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> While I was trying to fix IDENTITY-6315
>>>>>>> <htt

Re: [Dev] Remove outdated feature "Usage plan for the tenant"

[Johann Nallathamby]

IINM this comes from carbon-multitenancy. Not a identity feature. So if we
are removing it needs to be removed from all the products.

+1 to remove obsolete features if possible to avoid confusion. WSO2 Cloud
uses a completely different model I suppose.

On Sun, Sep 17, 2017 at 2:34 PM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> Since we are not using the following functionality we can remove this from
> management console and documentation.
>
> [1]* Usage plan for the tenant* - The usage plan defines limitations
> (such as number of users, bandwidth, etc.) for the tenant. The Identity
> Server comes with a predefined list, and you can add your item and/or
> tailor to the existing items. For on-premises deployment, there is only one
> default plan, i.e., Demo.
>
> Create a jira to track this[2]
>
> [1] https://docs.wso2.com/display/IS530/Creating+and+Managing+Tenants
>
> [2] https://wso2.org/jira/browse/IDENTITY-6457
> 
>
>
> Thanks,
> Nila.
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823 <+94%2077%20524%201823>
> Web : http://wso2.com/
>
>
> 
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Need to change the type of some variables to make the Identity Server, OIDC compliant.

[Johann Nallathamby]

I would like to see others comments also.

Since this is a spec violation do we need to be backward compatible? I
would say we don't have to be. But I know we can have users who want like
it to be a breaking change. So it's important what other IAM members think.

If we need to have a property we can have a blanket property for all such
backward incompatible changes in IS 5.4.0 and allow the user to configure,
without having one property for each change.

Regards,
Johann.

On Wed, Sep 20, 2017 at 1:40 PM, Dinusha Senanayaka 
wrote:

> Yes, this can break existing clients which has parsed current id_token and
> using these two values. One option is to introduce a new config to keep the
> old format of id_token and if the config value is switched, we support for
> the new format which is compliance for OIDC specification. We can deprecate
> supporting for old format after few releases.
>
> Regards,
> Dinusha
>
> On Wed, Sep 20, 2017 at 9:26 AM, Hasini Witharana 
> wrote:
>
>> Hi,
>>
>> OIDC test suite has been updated and now new issues have come in basic
>> profile (where response_type=code). The issues are given below.
>>
>> 1. OP-scope-email
>>  In here email_verified is returned as a string in id_token and it
>> should be a boolean value.
>>
>> 2. OP-scope-phone
>>  In here phone_number_verified is returned as a string in id_token
>> and it should be a booleanvalue.
>>
>> If we change these parameters to return boolean values, will the existing
>> users get effected by that?
>>
>> Thank you.
>> --
>>
>> *Hasini Witharana*
>> Software Engineering Intern | WSO2
>>
>>
>> *Email : hasi...@wso2.com *
>>
>> *Mobile : +94713850143 <071%20385%200143>[image:
>> http://wso2.com/signature] *
>>
>
>
>
> --
> Dinusha Dilrukshi
> Technical Lead
> WSO2 Inc.: http://wso2.com/
> Mobile: +94764069991 <+94%2076%20406%209991>
> Blog: http://dinushasblog.blogspot.com/
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Resource value of OIDC discovery

[Johann Nallathamby]

Also if the discovery endpoint is secured with the authorization valve then
cross tenant restriction is enforced at the valve itself. That is if the
authenticating user's tenant domain is not matching with the resource's
tenant domain, unless we have enabled cross tenant access in the valve it
must throw an error.

*@Hasanthi*: Is the valve enabled for cross tenant access by default? Can
you how it is able to pass the valve and go?

Regards,
Johann.

On Tue, Sep 19, 2017 at 10:17 AM, Maduranga Siriwardena 
wrote:

> Hi Hasanthi,
>
> To start discovery of OpenID endpoints, the End-User supplies an
> Identifier to the Relying Party. The RP applies normalization rules to the
> Identifier to determine the Resource and Host. One form of resource is
> "userinfo@host" format. If the resource is in this format, RP needs to
> prefix acct: to identifier string as scheme (see the normalization steps in
> [1]). So in our samples "admin@localhost" says userinfo is "admin" and
> host is "localhost".
>
> Specification clearly explains the formats of the resource value and so we
> can't just use the tenant domain as a resource.
>
> I think we need to validate username also before sending the response.
>
> [1] https://openid.net/specs/openid-connect-discovery-1_0.
> html#NormalizationSteps
>
> On Tue, Sep 19, 2017 at 9:24 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Also Why do we append  "acct:" in-front of the user name here? I think
>> we need to mention all those things in te documentation as well.
>>
>> Thanks
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>> On Mon, Sep 18, 2017 at 11:16 PM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 18, 2017 at 10:58 PM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi All,
 I need to clarify few points on OIDC discovery with wso2 IS 5.3.0.  If
 we consider a sample request to webfinger as below:

 Super tenant:
 curl -v -k --user admin:admin https://localhost:9443/.well-k
 nown/webfinger?resource='acct:admin@localhost=http://ope
 nid.net/specs/connect/1.0/issuer'

 Other tenants:
 curl -v -k --user admin:admin https://localhost:9443/.well-k
 nown/webfinger?resource='acct:hasanthi%40wso2.com@localhost=
 http://openid.net/specs/connect/1.0/issuer'

>>> Why we use super tenant credentials for authentication in tenanted case
>>> ?
>>>

 Here if we consider the tenant case, even if there is no user as
 'hasanthi' presents in the tenant domain 'wso2.com' it returns a
 successful result.

 The spec explains the resource as below:
 resource :
 Identifier for the target End-User that is the subject of the discovery
 request.

 As this endpoint can be used publicly may be we are not validating the
 user as it exposes too much data to the out side. So we may only validate
 user here. But I am wondering why we don't just use the tenant domain as
 the resource name here without using a dummy user name which has no value.
 Is there any reason for that?

 Also Can someone please explain why do we need to append @localhost at
 the end of the resource name. I think we should explain the reason for this
 in our docs as well.

 Thanks,


 Hasanthi Dissanayake

 Software Engineer | WSO2

 E: hasan...@wso2.com
 M :0718407133| http://wso2.com 

>>>
>>>
>>>
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591 <+94%2071%20899%200591>
> Blog: *https://madurangasiriwardena.wordpress.com/
> *
> 
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] IDENTITY-6405 seems to be a duplicate of IDENTITY-3966

[Johann Nallathamby]

Hi Nila,

IDENTITY-6405 seems to be a duplicate of IDENTITY-3966. At least they seem
to be very much related. Therefore I have resolved as duplicate. Please
reopen if that isn't the case.

Regards,
Johann.

-- Forwarded message --
From: Nilasini Thirunavukkarasu (JIRA) 
Date: Mon, Sep 11, 2017 at 2:05 PM
Subject: [Carbon-jira] [jira] (IDENTITY-6405) Could able to degrade the
permission of the logged in user's role it makes some unexpected behaviours
To: carbon-j...@wso2.org


Nilasini Thirunavukkarasu

*created* an issue

WSO2 Identity Server  / [image: Bug]
 IDENTITY-6405

Could able to degrade the permission of the logged in user's role it makes
some unexpected behaviours 
Issue Type: [image: Bug] Bug
Affects Versions: 5.4.0-Alpha2
Assignee: Darshana Gunawardana

Attachments: first_window, second_window.png
Components: user-mgt
Created: 11/Sep/17 2:04 PM
Fix Versions: 5.4.0-GA
Priority: [image: Highest] Highest
Reporter: Nilasini Thirunavukkarasu


1) Add a role with all permission
2) Assign the role to a user (say the user as nila)
3) Try to logged in with nila
4) Update the role by un tick all the permission or keep only login
permission
5) See the attachment for the output. (Attachments are added for the
scenario "keeping only login permission")
[image: Add Comment]
 Add Comment


This message was sent by Atlassian JIRA (v7.2.2#72004-sha1:9d51328)
[image: Atlassian logo]

___
Carbon-jira mailing list
carbon-j...@wso2.org
https://wso2.org/cgi-bin/mailman/listinfo/carbon-jira




-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Public JIRA resolved as Not A Bug without Reason

[Johann Nallathamby]

Sathya/IAM Folks,

It is not acceptable to resolve JIRAs without any reason. Can we please
include the reason as why it is not a bug? To me it looks like a clear bug.

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

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Shall We Link Corresponding IS Documentation as Context Sensitive Help Pages in IS Management Console?

[Johann Nallathamby]

On Tue, Sep 12, 2017 at 5:01 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> IMO Help link are good for a public facing application. E.g. API Store,
> Google Apps, etc. I don't think for a administrator application help link
> is necessary. Administrator applications are generally accompanied with a
> manual.
>

Just to be clear, what I meant is other large software ship with large
physical manuals or pdfs. So linking documentation from website is not
something I see commonly. And also it's going to be very difficult to find
and link specific sections. If linking documentation is going to be worse
experience than what is there now we shouldn't do it.

Having help pages was a good idea in the begining. But we haven't updated
it for a long time. So although updating the help links will be ideal,
given the time we have in our hand removing the links would be the optimal
solution if we want to fix this IMHO.


>
> Just my opinion.
>
> Regards,
> Johann.
>
> On Tue, Sep 12, 2017 at 4:43 PM, Thilina Madumal <thilina...@wso2.com>
> wrote:
>
>> Hi Samuel,
>>
>> On Tue, Sep 12, 2017 at 9:38 AM, Samuel Gnaniah <sam...@wso2.com> wrote:
>>
>>> If the user needs to refer to the documentation to fill a form in the
>>> UI, that means the UI is not intuitive enough for the user. Better UX is a
>>> better and more sustainable solution, even if it means a wider set of
>>> changes in the short term.
>>>
>>
>> I sugessted this idea in an earlier reply to this thread. But as we
>> consider the practical perspective I would like to make some changes to
>> that idea.
>>
>>1. I don't stand with removing the help links completely. I would
>>rather (as minoli have sugested) go with linking IS documentation with
>>those links.
>>2. Making UI intuitive is a good option but it is a progressive
>>effort. On the other hand even though we achieved it we can't let go of
>>help documentation because it is not feasible to achieve that level of UI
>>intuitivity.
>>
>>
>>> --
>>>
>>> *Samuel Gnaniah*
>>> Lead Technical Writer
>>>
>>> WSO2 (pvt.) Ltd.
>>> Colombo, Sri Lanka
>>> (+94) 773131798 <+94%2077%20313%201798>
>>>
>>> On Tue, Sep 12, 2017 at 9:31 AM, Minoli Perera <mino...@wso2.com> wrote:
>>>
>>>> IMO we should link the specific documentation pages related to the page
>>>> topics without completely removing help link, then if the user needs help
>>>> s/he need not search for the related content. Even though It is not
>>>> accessible without internet for most of the cases it will be helpful.
>>>>
>>>> Thanks,
>>>> Minoli
>>>>
>>>> On Tue, Sep 5, 2017 at 2:26 PM, Darshana Gunawardana <darsh...@wso2.com
>>>> > wrote:
>>>>
>>>>> +1 to remove this.
>>>>>
>>>>> This is something comes from kernel right? So this is something has to
>>>>> agree with all products.
>>>>>
>>>>> Are we ok to remove this in a kernel patch release?
>>>>>
>>>>> On Tue, Sep 5, 2017 at 1:58 PM, Shiraz Azad <shi...@wso2.com> wrote:
>>>>>
>>>>>> Agree with Thilina. At the same time, we should make sure we dont
>>>>>> clutter the UI with explaining notes. In that case, a UI guide will be
>>>>>> really effective. +1 for that.
>>>>>>
>>>>>> Thanks
>>>>>> Shiraz
>>>>>>
>>>>>> On Mon, Sep 4, 2017 at 10:41 AM, Thilina Madumal <thilina...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> For the 5.4.0 we have to go with the assumption that the current
>>>>>>> Implementation of the UI, self-explain enough.
>>>>>>> With that assumption, we can go ahead and can remove the help links.
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Making UI self-explain better can be achieved in the 5.5.0 release
>>>>>>> since there is a plan to re-write the UI.
>>>>>>> For that, I suggest implementing something like UI guide (something
>>>>>>> similar to what APIM has done, IMO it is pretty effective) when a user
>>>>>>> starts a fresh pack.
>>>>>>>
>>>>>>> Regards,
>>

Re: [Dev] Avoid Invoking REST endpoints from SSO login page

[Johann Nallathamby]

On Sat, Sep 16, 2017 at 1:46 PM, Farasath Ahamed <farasa...@wso2.com> wrote:

>
>
>
> On Sat, Sep 16, 2017 at 1:38 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> I also have the same concerns as Hasintha. The only viable solution seems
>> to be Pulasthi's which is to do the HEAD call to a URL which we know that
>> doesn't consume much resources. If needed we can even introduce a resource
>> like that for this purpose if already not available. It's kind of like
>> having a ping service right? And also disable the client following
>> redirects.
>>
>
> If we are doing a HEAD call, we need to make sure to hostname verification
> configuration set at server level. Otherwise if someone wants to use our
> authentication endpoint they will be forced to fix certs etc. when trying
> with a hostname although there is flag to switch off hostname verifications.
>
> So far we only faced this situation(forced to changes certs when using
> with a hostname) only for dashboard logins since this HEAD was done
> specifically if the SP was dashboard. Now that we have enabled this for all
> service providers fixing the hostname verification will be important.
>

Yes. This needs to be fixed in IS as in other products. IINM APIM has fixed
this in their entire product. We need to have a util method in
identity-core and change every component that needs to open a https
connection outside to use this utility to create a connection.

However, for this particular issue I think there is an alternative. We can
do the HEAD call to "http://localhost; in the default pack. The ping URL
can be configured in web.xml. Anyone who sets up this webapp in a external
web container can change the web.xml configuration. They can use the
external DNS or internal DNS, which ever way they want it to work.

This will make sure our objectives are met. I.e. minimal configuration for
OOTB usage for better UX. And ability host the webapp in an external web
container.

Do you see problem?

Regards,
Johann.


>
>
>>
>> On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee <hasin...@wso2.com>
>> wrote:
>>
>>> Can we alter a config inside webapp easily ? I mean if another product
>>> wants to change the config in order to change the OOTB behaviour, it has to
>>> extract and change the config at product build time. Is this
>>> straightforward to a config inside a webapp ? On the other hand we cannot
>>> move this config to a file which stays out of the webapp. It's not correct
>>> since authentication endpoint should be ideally self contained.
>>>
>>> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe <
>>> nuwan...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed <farasa...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana <
>>>>> pulast...@wso2.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee <hasin...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think we must avoid this if this is just to check whether the
>>>>>>> endpoint exists or not. This is anyway a costly operation. Head will 
>>>>>>> only
>>>>>>> reduce the transport cost. Otherwise when the head request reaches back
>>>>>>> end, it does the relevant operation treating the request as a GET and 
>>>>>>> avoid
>>>>>>> responding with actual payload. In our case this is very costly because
>>>>>>> within these calls, there are user store accesses and multiple other DB
>>>>>>> accesses.
>>>>>>>
>>>>>>
>>>>>> We'll need that check (or some other way) to check whether the
>>>>>> identity mgt webapp exists and deployed since some products don't ship it
>>>>>> by default. And yes, we need to get rid of calling an endpoint which does
>>>>>> any heavy work. So shall we do the HEAD to a page which does not do any
>>>>>> heavy work? May be to "accountrecoveryendpoint/error.jsp"?
>>>>>>
>>>>>
>>>>> Wouldn't it be easier if we do this with a config.
>>>>> ie. By default we do not show these links. If any product ships the
>>>>> account recovery endpoint  and they want to show the recovery links for 
>>>

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Johann Nallathamby]

On Sat, Sep 16, 2017 at 1:37 PM, Farasath Ahamed <farasa...@wso2.com> wrote:

>
>
>
>
> On Sat, Sep 16, 2017 at 1:21 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Tenant domain of the application should always be read from the resource
>> path - i.e. URL.
>>
>> We can't read it from the user since we will have to support SaaS mode,
>> which is to authenticate with a super tenant user and create the
>> application in a tenant.
>>
>
>
> Can we really do this? Authenticate from super tenant credentials and
> create an application in tenant?
>
> Our token endpoint derives the app's tenant domain from the tenantDomain
> of the user who created the app[1]. The assumption behind is that we can
> create apps across tenants. ie. A user from super tenant cannot go and
> create an app in a tenant.
>

I didn't think much about the DCR use case. I was talking in general. First
we need to think if SaaS scenario is applicable for DCR. If it is we need
to fix above limitation :). AFAIK above limitation comes because of the
limitation in the schema we have. And may be some model objects. Nothing
else. This is because OAuth2 was written way before IS 5.0.0 which
introduced SaaS concept. May be we even don't need to fix it immediately.
But we must follow same security pattern for all Rest endpoints, regardless
of limitations within the component.


>
>
> [1] https://github.com/wso2-extensions/identity-inbound-auth
> -oauth/blob/master/components/org.wso2.carbon.identity.
> oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/A
> ccessTokenIssuer.java#L129
>
>
>>
>> Please note that this is a standard pattern we follow in IS now, for
>> almost all endpoints. Therefore no one could be ignorant about it. Any new
>> Rest  endpoint development must follow the same security pattern. We do
>> this with the help of the Authn/Authz valve implemented by Harsha.
>>
>> Regards,
>> Johann.
>>
>> On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee <hasin...@wso2.com>
>> wrote:
>>
>>> Just asking for my knowledge,
>>>
>>> How do we identify the tenant domain of the application ? Do we have it
>>> in the context path ?, do we get it from user ?, or do we have anyway to
>>> convey it within the body (by appending to something) ? In a case if we get
>>> it from the identified user, how are we going to identify it from a request
>>> without any authentication mechanism ?.
>>>
>>> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana <ga...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana <hasi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In OIDC dynamic client registration, in the request header we need to
>>>>> send an already existing user and the password to register a client in 
>>>>> WSO2
>>>>> Identity server.In OIDC specification[1], It is not mandatory to send user
>>>>> details to register a client.
>>>>>
>>>>> When running the OIDC test suite for dynamic profile, test suite does
>>>>> not send any user details in the header. So we can't create any client and
>>>>> the test fails.
>>>>>
>>>>> For that issue if any user details are not provided in the
>>>>> registration request we can assign an anonymous user(*wso2*.
>>>>> *anonymous*.*user*) and register the client.
>>>>>
>>>> IMO correct design should be completely remove the requirement of
>>>> having a user. If we use *"wso2*.*anonymous*.*user" *some application
>>>> may have real username and some application may have *"wso2*.
>>>> *anonymous*.*user" *which end up with inconsistency.
>>>> Also need to think about creating a role per service provider if any
>>>> user doesn't have that role.
>>>>
>>>>>
>>>>> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>>>>>
>>>>> --
>>>>>
>>>>> *Hasini Witharana*
>>>>> Software Engineering Intern | WSO2
>>>>>
>>>>>
>>>>> *Email : hasi...@wso2.com <hasi...@wso2.com>*
>>>>>
>>>>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>>>>> http://wso2.com/signature] <http://wso2.com/signature>*
>>>>>
>>>>> --
>>&g

Re: [Dev] Avoid Invoking REST endpoints from SSO login page

[Johann Nallathamby]

I also have the same concerns as Hasintha. The only viable solution seems
to be Pulasthi's which is to do the HEAD call to a URL which we know that
doesn't consume much resources. If needed we can even introduce a resource
like that for this purpose if already not available. It's kind of like
having a ping service right? And also disable the client following
redirects.

On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee 
wrote:

> Can we alter a config inside webapp easily ? I mean if another product
> wants to change the config in order to change the OOTB behaviour, it has to
> extract and change the config at product build time. Is this
> straightforward to a config inside a webapp ? On the other hand we cannot
> move this config to a file which stays out of the webapp. It's not correct
> since authentication endpoint should be ideally self contained.
>
> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe  > wrote:
>
>>
>>
>> On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>


 On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee 
 wrote:

> I think we must avoid this if this is just to check whether the
> endpoint exists or not. This is anyway a costly operation. Head will only
> reduce the transport cost. Otherwise when the head request reaches back
> end, it does the relevant operation treating the request as a GET and 
> avoid
> responding with actual payload. In our case this is very costly because
> within these calls, there are user store accesses and multiple other DB
> accesses.
>

 We'll need that check (or some other way) to check whether the identity
 mgt webapp exists and deployed since some products don't ship it by
 default. And yes, we need to get rid of calling an endpoint which does any
 heavy work. So shall we do the HEAD to a page which does not do any heavy
 work? May be to "accountrecoveryendpoint/error.jsp"?

>>>
>>> Wouldn't it be easier if we do this with a config.
>>> ie. By default we do not show these links. If any product ships the
>>> account recovery endpoint  and they want to show the recovery links for all
>>> service provider logins, then they override this config at product level.
>>>
>> +1
>> Actually there is "IdentityManagementEndpointContextURL" parameter
>> configured in authenticationendpoint web.xml. Value of this parameter is
>> used to determine the recoveryendpoint url. As per the current
>> implementation, if this parameter is not configured, we retrieve the webapp
>> url by calling *IdentityUtil.getServerURL("/accountrecoveryendpoint",
>> true, true). *Can't we avoid showing the links if
>> *IdentityManagementEndpointContextURL* is not configured in
>> authentication endpoint? In the default pack, this parameter is commented
>> out. So anyone who needs it can un comment it.
>>
>> However with this implementation, the default behavior of dashboard login
>> page would change.
>>
>>>
>>> Another reason for this suggestion is that, upto IS 5.3.0 we only showed
>>> the recovery related links when login into user dashboard only. So this is
>>> essentially a change in the default behaviour of the product where we now
>>> show the recovery links in the login page for all service providers (not
>>> just the dashboard). So if someone wants to stick to the previous behaviour
>>> they should have a way to do so (ie. maintain backward compatibility).
>>>
>>
>>>


>
> On Fri, Aug 18, 2017 at 4:39 PM, Isura Karunaratne 
> wrote:
>
>>
>> On Fri, Aug 18, 2017 at 4:33 PM Malithi Edirisinghe <
>> malit...@wso2.com> wrote:
>>
>>> On Fri, Aug 18, 2017 at 4:02 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Malithi,

 On Fri, Aug 18, 2017 at 3:41 PM, Malithi Edirisinghe <
 malit...@wso2.com> wrote:

>
>
> On Fri, Aug 18, 2017 at 12:31 PM, Nuwandi Wickramasinghe <
> nuwan...@wso2.com> wrote:
>
>> Looks like http calls are done to validate the endpoint url. Do
>> we need this validation before showing the link?
>>
>> Shall we remove these calls and directly show the hyper link?
>>
>
> So here the validation is done as we are invoking another webapp.
> So that this check make sure a broken link is never to be shown in 
> this
> login page. Moreover, this is just a HEAD call so I don't think 
> invoking
> that impacts the login page performance, because the actual page is 
> not
> getting rendered here.
> The other thing is these webapps are coming from two features, so
> IMO, we cannot directly couple them together.
>

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Johann Nallathamby]

Tenant domain of the application should always be read from the resource
path - i.e. URL.

We can't read it from the user since we will have to support SaaS mode,
which is to authenticate with a super tenant user and create the
application in a tenant.

Please note that this is a standard pattern we follow in IS now, for almost
all endpoints. Therefore no one could be ignorant about it. Any new Rest
 endpoint development must follow the same security pattern. We do this
with the help of the Authn/Authz valve implemented by Harsha.

Regards,
Johann.

On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee 
wrote:

> Just asking for my knowledge,
>
> How do we identify the tenant domain of the application ? Do we have it in
> the context path ?, do we get it from user ?, or do we have anyway to
> convey it within the body (by appending to something) ? In a case if we get
> it from the identified user, how are we going to identify it from a request
> without any authentication mechanism ?.
>
> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana 
>> wrote:
>>
>>> Hi,
>>>
>>> In OIDC dynamic client registration, in the request header we need to
>>> send an already existing user and the password to register a client in WSO2
>>> Identity server.In OIDC specification[1], It is not mandatory to send user
>>> details to register a client.
>>>
>>> When running the OIDC test suite for dynamic profile, test suite does
>>> not send any user details in the header. So we can't create any client and
>>> the test fails.
>>>
>>> For that issue if any user details are not provided in the registration
>>> request we can assign an anonymous user(*wso2*.*anonymous*.*user*) and
>>> register the client.
>>>
>> IMO correct design should be completely remove the requirement of having
>> a user. If we use *"wso2*.*anonymous*.*user" *some application may have
>> real username and some application may have *"wso2*.*anonymous*.*user" *which
>> end up with inconsistency.
>> Also need to think about creating a role per service provider if any user
>> doesn't have that role.
>>
>>>
>>> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>>>
>>> --
>>>
>>> *Hasini Witharana*
>>> Software Engineering Intern | WSO2
>>>
>>>
>>> *Email : hasi...@wso2.com *
>>>
>>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>>> http://wso2.com/signature] *
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Engineering Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to engineering-group+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WSO2 Engineering Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to engineering-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Shall We Link Corresponding IS Documentation as Context Sensitive Help Pages in IS Management Console?

[Johann Nallathamby]

IMO Help link are good for a public facing application. E.g. API Store,
Google Apps, etc. I don't think for a administrator application help link
is necessary. Administrator applications are generally accompanied with a
manual.

Just my opinion.

Regards,
Johann.

On Tue, Sep 12, 2017 at 4:43 PM, Thilina Madumal <thilina...@wso2.com>
wrote:

> Hi Samuel,
>
> On Tue, Sep 12, 2017 at 9:38 AM, Samuel Gnaniah <sam...@wso2.com> wrote:
>
>> If the user needs to refer to the documentation to fill a form in the UI,
>> that means the UI is not intuitive enough for the user. Better UX is a
>> better and more sustainable solution, even if it means a wider set of
>> changes in the short term.
>>
>
> I sugessted this idea in an earlier reply to this thread. But as we
> consider the practical perspective I would like to make some changes to
> that idea.
>
>1. I don't stand with removing the help links completely. I would
>rather (as minoli have sugested) go with linking IS documentation with
>those links.
>2. Making UI intuitive is a good option but it is a progressive
>effort. On the other hand even though we achieved it we can't let go of
>help documentation because it is not feasible to achieve that level of UI
>intuitivity.
>
>
>> --
>>
>> *Samuel Gnaniah*
>> Lead Technical Writer
>>
>> WSO2 (pvt.) Ltd.
>> Colombo, Sri Lanka
>> (+94) 773131798 <+94%2077%20313%201798>
>>
>> On Tue, Sep 12, 2017 at 9:31 AM, Minoli Perera <mino...@wso2.com> wrote:
>>
>>> IMO we should link the specific documentation pages related to the page
>>> topics without completely removing help link, then if the user needs help
>>> s/he need not search for the related content. Even though It is not
>>> accessible without internet for most of the cases it will be helpful.
>>>
>>> Thanks,
>>> Minoli
>>>
>>> On Tue, Sep 5, 2017 at 2:26 PM, Darshana Gunawardana <darsh...@wso2.com>
>>> wrote:
>>>
>>>> +1 to remove this.
>>>>
>>>> This is something comes from kernel right? So this is something has to
>>>> agree with all products.
>>>>
>>>> Are we ok to remove this in a kernel patch release?
>>>>
>>>> On Tue, Sep 5, 2017 at 1:58 PM, Shiraz Azad <shi...@wso2.com> wrote:
>>>>
>>>>> Agree with Thilina. At the same time, we should make sure we dont
>>>>> clutter the UI with explaining notes. In that case, a UI guide will be
>>>>> really effective. +1 for that.
>>>>>
>>>>> Thanks
>>>>> Shiraz
>>>>>
>>>>> On Mon, Sep 4, 2017 at 10:41 AM, Thilina Madumal <thilina...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> For the 5.4.0 we have to go with the assumption that the current
>>>>>> Implementation of the UI, self-explain enough.
>>>>>> With that assumption, we can go ahead and can remove the help links.
>>>>>> WDYT?
>>>>>>
>>>>>> Making UI self-explain better can be achieved in the 5.5.0 release
>>>>>> since there is a plan to re-write the UI.
>>>>>> For that, I suggest implementing something like UI guide (something
>>>>>> similar to what APIM has done, IMO it is pretty effective) when a user
>>>>>> starts a fresh pack.
>>>>>>
>>>>>> Regards,
>>>>>> Thilina.
>>>>>>
>>>>>> On Sat, Sep 2, 2017 at 8:14 AM, Shiraz Azad <shi...@wso2.com> wrote:
>>>>>>
>>>>>>> +1. for removing links and making the UI self explained.
>>>>>>>
>>>>>>> Shiraz
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 31, 2017 at 7:07 PM, Thilina Madumal <
>>>>>>> thilina...@wso2.com> wrote:
>>>>>>>
>>>>>>>> +1 to remove the links as Johann has suggested.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Thilina.
>>>>>>>>
>>>>>>>> On Thu, Aug 31, 2017 at 11:40 AM, Johann Nallathamby <
>>>>>>>> joh...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> +1 to remove these links. I think better UX is the solution than
>>>>>&

Re: [Dev] [IS] GSoC 2017 - WS-Trust Implementation for IS6

[Johann Nallathamby]

Hi Maheshika,

Can we have repo created for this project under wso2-incubator?

Name: "mss4j-ws-trust"

Regards,
Johann.

On Tue, Sep 5, 2017 at 11:59 AM, Johann Nallathamby <joh...@wso2.com> wrote:

> Great job Isuranga over the past 3 months in completing this project!!
> Hope you had a great learning experience and will keep contributing to WSO2
> Identity Server in future.
>
> Can you please write a WSO2 article on the technical details of how this
> integration was done between MSS4J and CXF? We can publish that in our
> Oxygen Tank.
>
> And also you can write a blog post on how to integrate CXF as a
> WS-Security engine to any generic web services engine?
>
> Regards,
> Johann.
>
>
> On Tue, Sep 5, 2017 at 10:35 AM, Isuranga Perera <
> isurangamper...@gmail.com> wrote:
>
>> Hi All,
>>
>> I was able to complete the WS-Trust Implementation for Identity Server 6
>> with all the functional requirements.
>>
>> Project Repository [1]
>> Documentation [2]
>>
>> I would like to thanks my mentors Johann Nallathamby, Malithi
>> Edirisinghe, Kasun Gajasinghe who gave an immense support throughout the
>> project by giving necessary guidance whenever needed. In addition to that,
>> I would like to thanks,  Sagara Gunathnga, Harsha Thirimanne and Thusitha
>> Dayaratne for supporting me through Dev list.
>>
>> [1] https://github.com/IsurangaPerera/identity-inbound-auth-sts
>> [2] https://docs.google.com/document/d/1ZRLQnazRgH4ZZu2luxFm
>> YjXVpRw17n29NkkjeTXVWn0/edit?usp=sharing
>> <https://docs.google.com/document/d/1ZRLQnazRgH4ZZu2luxFmYjXVpRw17n29NkkjeTXVWn0/edit?usp=sharing>
>>
>> Best Regards
>> Isuranga Perera
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [IS] GSoC 2017 - WS-Trust Implementation for IS6

[Johann Nallathamby]

Great job Isuranga over the past 3 months in completing this project!! Hope
you had a great learning experience and will keep contributing to WSO2
Identity Server in future.

Can you please write a WSO2 article on the technical details of how this
integration was done between MSS4J and CXF? We can publish that in our
Oxygen Tank.

And also you can write a blog post on how to integrate CXF as a WS-Security
engine to any generic web services engine?

Regards,
Johann.


On Tue, Sep 5, 2017 at 10:35 AM, Isuranga Perera <isurangamper...@gmail.com>
wrote:

> Hi All,
>
> I was able to complete the WS-Trust Implementation for Identity Server 6
> with all the functional requirements.
>
> Project Repository [1]
> Documentation [2]
>
> I would like to thanks my mentors Johann Nallathamby, Malithi Edirisinghe,
> Kasun Gajasinghe who gave an immense support throughout the project by
> giving necessary guidance whenever needed. In addition to that, I would
> like to thanks,  Sagara Gunathnga, Harsha Thirimanne and Thusitha Dayaratne
> for supporting me through Dev list.
>
> [1] https://github.com/IsurangaPerera/identity-inbound-auth-sts
> [2] https://docs.google.com/document/d/1ZRLQnazRgH4ZZu2luxFm
> YjXVpRw17n29NkkjeTXVWn0/edit?usp=sharing
> <https://docs.google.com/document/d/1ZRLQnazRgH4ZZu2luxFmYjXVpRw17n29NkkjeTXVWn0/edit?usp=sharing>
>
> Best Regards
> Isuranga Perera
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] Some concerns on IDENTITY-6324

[Johann Nallathamby]

Hi Isura,

On Mon, Sep 4, 2017 at 9:35 PM, Isura Karunaratne <is...@wso2.com> wrote:

> Hi Johann,
>
> On Mon, Sep 4, 2017 at 8:18 PM Johann Nallathamby <joh...@wso2.com> wrote:
>
>> Hi Hasanthi/Nuwandi/IAM Team,
>>
>> 1. Can we please add a description in the JIRA as to what this JIRA is
>> for?
>>
>> 2. The fix has made a public enum change:
>> "MAX_ATTEMTS_EXCEEDED" -> "MAX_ATTEMTS_EXCEEDED".
>> Is this intentional? In any case the spelling is still wrong.
>>
>> 3. We have introduced a new protected method "
>> setUserClaimsValuesInUserStore". Again is this intentional? And we have
>> a threadlocal solution to prevent listenered being triggered twice. In that
>> case do we need this new method?
>>
>
> Here we are going to support account locking failure reason. In that case,
> we need a way to identify following account lock reasons separately.
>
> - Admin Lock User Account
> - Account not confirmed
> - Account locked due to exceeding max failure attempts
>
> We have to check account lock claim in setUserClaimValues method to check
> whether admin user is going to lock a user. Since the recursion in
> UserStoreBasedIdentityDaaStore, we can't put that logic inside
> setUserClaimValues method, because we use setUserClaimValues method to
> store the reason for other scenarios as well.
>

Simply we could check for the appropriate conditions using both the account
lock claim and the lock reason claim. This way we can differentiate between
the different conditions. This isn't that complicated is it? I know with
multiple if-else conditions this becomes a bit confusing for people, but
that is a problem in our pre IS 5.3.0 where all the code was written in the
listener (code to handle various scenarios and code to persist identity
claims). In IS 5.3.0 we have separated out the persisting logic and the
logic to handle various identity management scenarios to different handler
classes. So it should be much more simpler to understand.

Why I don't like the current fix is that it is purposely skipping the
listeners. We had the same solutions in IS 5.0.0 and removed it to avoid
skipping listeners by down casting to the specific UserStoreManagers,
because then the solution doesn't work for custom user store managers. Now
we are going back to the same solution. This issue is simple logic error. I
don't think we need to do such a change and go back to something we removed
earlier sighting other bigger concerns.

I already discussed this offline with *@Farasath.* He knows what I am
talking about.

Shall we change the fix and not change the model altogether?

Btw, did we test the same in the new implementation in IS 5.3.0? How do it
do there?

Regards,
Johann.


>
>
> Thanks
> Isura.
>
>
>> [1] https://wso2.org/jira/browse/IDENTITY-6324
>>
>> Thanks & Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.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/
>
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

[Dev] Shall we remove InfoRecoverySample from product-is?

[Johann Nallathamby]

If we are going to keep it in product-is we need to maintain compatibility
with latest APIs. But I think we have even resolved some public JIRAs
mentioning the fact that we now support this in identity-mgt webapp. So we
don't need a separate sample for this.

So, I think we can do $subject.

Regards,
Johann.

-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Some concerns on IDENTITY-6324

[Johann Nallathamby]

Hi Hasanthi/Nuwandi/IAM Team,

1. Can we please add a description in the JIRA as to what this JIRA is for?

2. The fix has made a public enum change:
"MAX_ATTEMTS_EXCEEDED" -> "MAX_ATTEMTS_EXCEEDED".
Is this intentional? In any case the spelling is still wrong.

3. We have introduced a new protected method
"setUserClaimsValuesInUserStore". Again is this intentional? And we have a
threadlocal solution to prevent listenered being triggered twice. In that
case do we need this new method?

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

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] (IDENTITY-5948) Can't we do a better fix for this?

[Johann Nallathamby]

On Mon, Sep 4, 2017 at 3:02 PM, Rushmin Fernando <rush...@wso2.com> wrote:

> Hi Johann,
>
> The fix handles the tenant scenario as well.
>
> Are you specifically talking about having different domain names for
> tenants?
>

Yes.


>
> Best Regards,
> Rushmin
>
>
> On Mon, Sep 4, 2017 at 2:59 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi Rushmin,
>>
>> I think the better, easier, uncomplicated fix that also works for tenants
>> will be to make this a text box with a default value instead of a label.
>>
>> Can we change the fix like that?
>>
>> Regards,
>> Johann.
>>
>> On Fri, Sep 1, 2017 at 5:17 PM, Rushmin Fernando <rush...@wso2.com>
>> wrote:
>>
>>> Thank you for pointing this out Johann.
>>>
>>> Actually, the code doesn't do anything specific to the super tenant.
>>>
>>> The issue is with method name 'updateSuperTenantIdpWithNewEPUrls' which
>>> is incorrect and misleading. It was my mistake :-(
>>>
>>> I just sent a PR [1] fixing the method name.
>>>
>>> @Darshana, could you review and merge it.
>>>
>>> Best Regards,
>>> Rushmin
>>>
>>> [1] - https://github.com/wso2/carbon-identity-framework/pull/1043
>>>
>>> On Thu, Aug 31, 2017 at 6:09 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> IAM Folks,
>>>>
>>>> Can we do a better fix for this? I don't seem to agree with this fix.
>>>>
>>>> 1. We have written super tenant specific code. We shows that we treat
>>>> super tenant differently and can be error prone.
>>>> 2. The problem still remains for already created tenants.
>>>>
>>>> Another thing we need to address is that (not related to this issue),
>>>> some deployments require to have different DNS names for tenants.
>>>>
>>>> My suggestion:
>>>> Make this field a text box that is modifiable.
>>>>
>>>> Wdyt? Can we change this fix for IS 5.4.0? Do you see any problems in
>>>> that?
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>> -- Forwarded message --
>>>> From: Farasath Ahamed (JIRA) <j...@wso2.org>
>>>> Date: Thu, May 18, 2017 at 1:54 AM
>>>> Subject: [Carbon-jira] [jira] (IDENTITY-5948) Generated IdP metadata
>>>> URLs are always pointing to localhost:9443
>>>> To: carbon-j...@wso2.org
>>>>
>>>>
>>>> Farasath Ahamed
>>>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=farasatha%40wso2.com>
>>>> *created* an issue
>>>>
>>>> WSO2 Identity Server <https://wso2.org/jira/browse/IDENTITY> / [image:
>>>> Improvement] <https://wso2.org/jira/browse/IDENTITY-5948> IDENTITY-5948
>>>> <https://wso2.org/jira/browse/IDENTITY-5948>
>>>> Generated IdP metadata URLs are always pointing to localhost:9443
>>>> <https://wso2.org/jira/browse/IDENTITY-5948>
>>>> Issue Type: [image: Improvement] Improvement
>>>> Affects Versions: 5.3.0-GA
>>>> Assignee: Thanuja Lakmal
>>>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=thanuja%40wso2.com>
>>>> Components: saml2-sso
>>>> Created: 18/May/17 1:53 AM
>>>> Fix Versions: 5.3.1-GA
>>>> Priority: [image: High] High
>>>> Reporter: Farasath Ahamed
>>>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=farasatha%40wso2.com>
>>>>
>>>> During the first startup if we do not change the hostname of the IS
>>>> server.
>>>> All endpoints related to SAML configs gets generated for localhost.
>>>>
>>>> Thereafter even if you change the hostname still they will remain as
>>>> hostname,
>>>>
>>>> >>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 
>>>> entityID="localhost">>>> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" 
>>>> validUntil="2017-05-17T21:20:17.955Z">>>> use="signing">>>> xmlns="http://www.w3.org/2000/09/xmldsig#;>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
>>>> Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
>

Re: [Dev] [IAM] (IDENTITY-5948) Can't we do a better fix for this?

[Johann Nallathamby]

Hi Rushmin,

I think the better, easier, uncomplicated fix that also works for tenants
will be to make this a text box with a default value instead of a label.

Can we change the fix like that?

Regards,
Johann.

On Fri, Sep 1, 2017 at 5:17 PM, Rushmin Fernando <rush...@wso2.com> wrote:

> Thank you for pointing this out Johann.
>
> Actually, the code doesn't do anything specific to the super tenant.
>
> The issue is with method name 'updateSuperTenantIdpWithNewEPUrls' which
> is incorrect and misleading. It was my mistake :-(
>
> I just sent a PR [1] fixing the method name.
>
> @Darshana, could you review and merge it.
>
> Best Regards,
> Rushmin
>
> [1] - https://github.com/wso2/carbon-identity-framework/pull/1043
>
> On Thu, Aug 31, 2017 at 6:09 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> IAM Folks,
>>
>> Can we do a better fix for this? I don't seem to agree with this fix.
>>
>> 1. We have written super tenant specific code. We shows that we treat
>> super tenant differently and can be error prone.
>> 2. The problem still remains for already created tenants.
>>
>> Another thing we need to address is that (not related to this issue),
>> some deployments require to have different DNS names for tenants.
>>
>> My suggestion:
>> Make this field a text box that is modifiable.
>>
>> Wdyt? Can we change this fix for IS 5.4.0? Do you see any problems in
>> that?
>>
>> Regards,
>> Johann.
>>
>> -- Forwarded message --
>> From: Farasath Ahamed (JIRA) <j...@wso2.org>
>> Date: Thu, May 18, 2017 at 1:54 AM
>> Subject: [Carbon-jira] [jira] (IDENTITY-5948) Generated IdP metadata URLs
>> are always pointing to localhost:9443
>> To: carbon-j...@wso2.org
>>
>>
>> Farasath Ahamed
>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=farasatha%40wso2.com>
>> *created* an issue
>>
>> WSO2 Identity Server <https://wso2.org/jira/browse/IDENTITY> / [image:
>> Improvement] <https://wso2.org/jira/browse/IDENTITY-5948> IDENTITY-5948
>> <https://wso2.org/jira/browse/IDENTITY-5948>
>> Generated IdP metadata URLs are always pointing to localhost:9443
>> <https://wso2.org/jira/browse/IDENTITY-5948>
>> Issue Type: [image: Improvement] Improvement
>> Affects Versions: 5.3.0-GA
>> Assignee: Thanuja Lakmal
>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=thanuja%40wso2.com>
>> Components: saml2-sso
>> Created: 18/May/17 1:53 AM
>> Fix Versions: 5.3.1-GA
>> Priority: [image: High] High
>> Reporter: Farasath Ahamed
>> <https://wso2.org/jira/secure/ViewProfile.jspa?name=farasatha%40wso2.com>
>>
>> During the first startup if we do not change the hostname of the IS
>> server.
>> All endpoints related to SAML configs gets generated for localhost.
>>
>> Thereafter even if you change the hostname still they will remain as
>> hostname,
>>
>> > xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 
>> entityID="localhost">> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" 
>> validUntil="2017-05-17T21:20:17.955Z">> xmlns="http://www.w3.org/2000/09/xmldsig#;>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
>> Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
>> CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
>> AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
>> sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
>> HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
>> AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
>> QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
>> O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=>  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
>> Location="https://localhost:9443/samlsso; 
>> ResponseLocation="https://localhost:9443/samlsso"/>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified>  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
>> Location="https://localhost:9443/samlsso"/>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
>> Location="https://localhost:9443/samlsso"/>
>>
>> Any new tenants created after the hostname change wil

Re: [Dev] Should we trim usernames when authenticating at UserStore level?

[Johann Nallathamby]

+1

It should be consistent and I also don't think we should be trimming.

On Sun, Sep 3, 2017 at 12:40 PM, Farasath Ahamed  wrote:

> Hi Devs,
>
> Noticed that we trim the username when performing authentication in LDAP
> and AD Userstore Managers[1]. But we do not do trim the username in
> JDBCUserStoreManager[2]?
>
> IMO we should have the similar behaviour for all the user stores, ie.
> either we trim the username in each of them or we don't trim in any of them?
>
> On the other hand, I think we shouldn't trim the username at all since it
> leads to issue like[3], where the authentication was successful because of
> trimming the spaces silently but claims retrieval etc. fails due to the
> incorrect username with extra spaces.
>
> Appreciate your thoughts!
>
>
> [1] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/
> org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/ldap/
> ReadOnlyLDAPUserStoreManager.java#L357
>
> [2] https://github.com/wso2/carbon-kernel/blob/
> f551d3530300a43ca1afc2a56d62be34f2d72320/core/org.wso2.
> carbon.user.core/src/main/java/org/wso2/carbon/user/core/jdbc/
> JDBCUserStoreManager.java#L1152-L1235
>
> [3] https://wso2.org/jira/browse/IDENTITY-5864
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [GSoC] SCIM 2.0 Compliance Test Suite

[Johann Nallathamby]

Hi Vindula,

Great contribution!! :) Since we are going to promote use of SCIM 2.0 from
IS 5.4.0 onwards this compliance test suite will life much easier with
fixes and improvements we are going to add to SCIM 2.0 implementation.

*@Darshana/Omindu*:
How do we plan to integrate this with our test framework? Or any other ways
of integrating this to our jenkins build so that SCIM 2.0 tests are aways
run before a release?

Regards,
Johann.

On Mon, Aug 28, 2017 at 1:49 PM, Vindula Jayawardana <
vindula...@cse.mrt.ac.lk> wrote:

> Hi All,
>
> I submitted the completed project and thanks a lot for reviewing and
> merging the PR [1]. Please find below the final related links for the SCIM
> 2.0 Compliance Test Suite.
>
>- Github repo: scim2-compliance-test-suite [2]
>- Blog on the project: SCIM 2.0 Compliance Test Suite — GSoC 2017 with
>WSO2 [3]
>- Screencast of the test suite: SCIM 2.0 Compliance Test Suite Demo [4]
>- Project readme [5]
>
> [1]: https://github.com/wso2-incubator/scim2-compliance-test-suite/pull/1
> [2]: https://github.com/wso2-incubator/scim2-compliance-test-suite
> [3]: https://medium.com/@vindulajayawardana/scim-2-0-
> compliance-test-suite-737fd4ace3cc
> [4]: https://www.youtube.com/watch?v=XJ53x_8oAWg=youtu.be
> [5]: https://github.com/wso2-incubator/scim2-compliance-
> test-suite/blob/master/README.md
>
> Please let me know if there is anything that needs to be done by my end.
>
> Thank you,
> *Vindula Jayawardana*
> Computer Science and Engineering Dept.
> University of Moratuwa
> mobile : +713462554
> Email : vindula...@cse.mrt.ac.lk
>
> 
> 
> 
> 
>
> *“Respect is how to treat everyone, not just those you want to impress. "*
>
>
> *-Richard Branson-*
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

[Johann Nallathamby]

In that case can we set a threadlocal variable in order to identify the
SCIM version? Based on that the correct listener will execute and the other
will not. Since SCIM1.1 listener will check for it's related threadlocal
and SCIM2.0 listener it's related threadlocal there is not coupling between
the two implementations. All the SCIM operations must set this threadlocal.
I don't see any better solution for this problem.

Regards,
Johann.

On Thu, Aug 31, 2017 at 6:54 PM, Sathya Bandara <sat...@wso2.com> wrote:

>
>
> On Thu, Aug 31, 2017 at 2:18 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi Sathya,
>>
>> On Thu, Aug 31, 2017 at 12:29 PM, Sathya Bandara <sat...@wso2.com> wrote:
>>
>>> Hi Johann,
>>>
>>> IMO having two separate LDAP attributes for the same claims in both
>>> SCIM1 and SCIM2 would be redundant and cause problems in maintaining user
>>> attributes.
>>>
>>
>> True. I didn't say this is the correct solution. I only mentioned it as a
>> work around for someone who wants to use both without any conflicts until
>> we find a alternative or deprecate SCIM 1.1 :)
>>
>>
>>> If we need to have both listeners enabled at the time I would suggest to
>>> use a common util method to generate IDs and do the mappings for the claims
>>> that are common to both protocols.
>>>
>>
>> Didn't get how this would help exactly. May be I am missing some context.
>>
>> However, after reading through your first reply again, now I have another
>> question. Why do both the listeners get executed when adding a new user? I
>> know they both will get triggered. But can't we look at the dialect URI at
>> the top and skip the execution if it's not for that listener?
>>
>> When adding a user through normal approach(management console) when SCIM
>> is enabled, it is not possible to figure out the dialect URI. In this case
>> this will not work AFAIU.
>>
>
Hmm..


>
>> Thanks,
>> Sathya
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> Thanks,
>>> Sathya
>>>
>>> On Thu, Aug 31, 2017 at 11:37 AM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Will it work if we have two separate attributes for the problematic
>>>> attributes like SCIM ID? If that works I guess that is one solution.
>>>>
>>>> Or we need to have one listener for both SCIM 1 and SCIM2. But don't
>>>> think that's a good solution. Introduces direct coupling between two
>>>> implementations.
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>> On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara <sat...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Thilina,
>>>>>
>>>>> If we enable both SCIM1 and SCIM2 listeners at the same time two
>>>>> different SCIM IDs will be generated for the same user when adding a new
>>>>> user through SCIM. Also both SCIM1 and SCIM2 claims are mapped to the same
>>>>> LDAP user attributes. Even though both listeners get triggered only the
>>>>> SCIM1 ID is mapped to the user ID attribute. But the SCIM2 user creation
>>>>> response will contain the SCIM ID generated by SCIM2 listener.
>>>>>
>>>>> Thanks,
>>>>> Sathya
>>>>>
>>>>> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal <thilina...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> While I was trying to fix IDENTITY-6315
>>>>>> <https://wso2.org/jira/browse/IDENTITY-6315> I got to know that we
>>>>>> can't enable both SCIM1 and SCIM2 at the same time in WSO2 Identity 
>>>>>> Server.
>>>>>> Is it because of this specific issue or is there any other reasons?
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Thilina.
>>>>>>
>>>>>> --
>>>>>> *Thilina Madumal*
>>>>>> *Software Engineer | **WSO2*
>>>>>> Email: thilina...@wso2.com
>>>>>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>>>>>> Web:  <http://goog_716986954>http://wso2.com
>>>>>>
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>
>>>>>
>

[Dev] [IAM] (IDENTITY-5948) Can't we do a better fix for this?

[Johann Nallathamby]

IAM Folks,

Can we do a better fix for this? I don't seem to agree with this fix.

1. We have written super tenant specific code. We shows that we treat super
tenant differently and can be error prone.
2. The problem still remains for already created tenants.

Another thing we need to address is that (not related to this issue), some
deployments require to have different DNS names for tenants.

My suggestion:
Make this field a text box that is modifiable.

Wdyt? Can we change this fix for IS 5.4.0? Do you see any problems in that?

Regards,
Johann.

-- Forwarded message --
From: Farasath Ahamed (JIRA) 
Date: Thu, May 18, 2017 at 1:54 AM
Subject: [Carbon-jira] [jira] (IDENTITY-5948) Generated IdP metadata URLs
are always pointing to localhost:9443
To: carbon-j...@wso2.org


Farasath Ahamed

*created* an issue

WSO2 Identity Server  / [image:
Improvement]  IDENTITY-5948

Generated IdP metadata URLs are always pointing to localhost:9443

Issue Type: [image: Improvement] Improvement
Affects Versions: 5.3.0-GA
Assignee: Thanuja Lakmal

Components: saml2-sso
Created: 18/May/17 1:53 AM
Fix Versions: 5.3.1-GA
Priority: [image: High] High
Reporter: Farasath Ahamed


During the first startup if we do not change the hostname of the IS server.
All endpoints related to SAML configs gets generated for localhost.

Thereafter even if you change the hostname still they will remain as
hostname,

http://www.w3.org/2000/09/xmldsig#;>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=https://localhost:9443/samlsso;
ResponseLocation="https://localhost:9443/samlsso"/>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedhttps://localhost:9443/samlsso"/>https://localhost:9443/samlsso"/>

Any new tenants created after the hostname change will have the correct URL
with the hostname. But super tenant's metadata URL becomes unusable.

Basically, the endpoint in SAML Metadata file is static values.
IMO we should generate them dynamically so that any change to an
environment parameter would be reflected correctly.
[image: Add Comment]
 Add Comment


This message was sent by Atlassian JIRA (v7.2.2#72004-sha1:9d51328)
[image: Atlassian logo]

___
Carbon-jira mailing list
carbon-j...@wso2.org
https://wso2.org/cgi-bin/mailman/listinfo/carbon-jira




-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] List of claims returned in IDToken and Userinfo don't get updated when we update requested claims configuration

[Johann Nallathamby]

IAM Folks,

List of claims returned in IDToken and Userinfo don't get updated when we
update requested claims configuration. This doesn't get updated even if we
try from a fresh browser instance. The only way to get out of this seems to
be revoking the token.

This seems to be a big usability issue for evaluation users and first
experience becomes really bad.  Can we get this fixed for IS 5.4.0 [1]?

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

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Unable to create user with "email verification" and "request password" using SCIM

[Johann Nallathamby]

IAM Folks,

Following seems to be a blocker for IS 5.4.0 and we need to immediately fix
this.

The only Rest API we have now to create new users is SCIM. And we are not
able to create users with "email verification" and "request password".

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

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

[Johann Nallathamby]

Hi Sathya,

On Thu, Aug 31, 2017 at 12:29 PM, Sathya Bandara <sat...@wso2.com> wrote:

> Hi Johann,
>
> IMO having two separate LDAP attributes for the same claims in both SCIM1
> and SCIM2 would be redundant and cause problems in maintaining user
> attributes.
>

True. I didn't say this is the correct solution. I only mentioned it as a
work around for someone who wants to use both without any conflicts until
we find a alternative or deprecate SCIM 1.1 :)


> If we need to have both listeners enabled at the time I would suggest to
> use a common util method to generate IDs and do the mappings for the claims
> that are common to both protocols.
>

Didn't get how this would help exactly. May be I am missing some context.

However, after reading through your first reply again, now I have another
question. Why do both the listeners get executed when adding a new user? I
know they both will get triggered. But can't we look at the dialect URI at
the top and skip the execution if it's not for that listener?

Regards,
Johann.


>
> Thanks,
> Sathya
>
> On Thu, Aug 31, 2017 at 11:37 AM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Will it work if we have two separate attributes for the problematic
>> attributes like SCIM ID? If that works I guess that is one solution.
>>
>> Or we need to have one listener for both SCIM 1 and SCIM2. But don't
>> think that's a good solution. Introduces direct coupling between two
>> implementations.
>>
>> Regards,
>> Johann.
>>
>> On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara <sat...@wso2.com> wrote:
>>
>>> Hi Thilina,
>>>
>>> If we enable both SCIM1 and SCIM2 listeners at the same time two
>>> different SCIM IDs will be generated for the same user when adding a new
>>> user through SCIM. Also both SCIM1 and SCIM2 claims are mapped to the same
>>> LDAP user attributes. Even though both listeners get triggered only the
>>> SCIM1 ID is mapped to the user ID attribute. But the SCIM2 user creation
>>> response will contain the SCIM ID generated by SCIM2 listener.
>>>
>>> Thanks,
>>> Sathya
>>>
>>> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal <thilina...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>> While I was trying to fix IDENTITY-6315
>>>> <https://wso2.org/jira/browse/IDENTITY-6315> I got to know that we
>>>> can't enable both SCIM1 and SCIM2 at the same time in WSO2 Identity Server.
>>>> Is it because of this specific issue or is there any other reasons?
>>>>
>>>> Thanks & Regards,
>>>> Thilina.
>>>>
>>>> --
>>>> *Thilina Madumal*
>>>> *Software Engineer | **WSO2*
>>>> Email: thilina...@wso2.com
>>>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>>>> Web:  <http://goog_716986954>http://wso2.com
>>>>
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sathya Bandara
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com
>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>
>>> <+94%2071%20411%205032>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [IS] Shall We Link Corresponding IS Documentation as Context Sensitive Help Pages in IS Management Console?

[Johann Nallathamby]

+1 to remove these links. I think better UX is the solution than asking
users to read more docs.

Regards,
Johann.

On Thu, Aug 31, 2017 at 11:04 AM, Samuel Gnaniah <sam...@wso2.com> wrote:

> Our strategy here is to remove these help links and walk through the UI
> with the dev team to make the UIs and forms easier to configure without
> requiring additional documentation. This is the stragety we are following
> for all products.
>
> Thanks,
>
> --
>
> *Samuel Gnaniah*
> Lead Technical Writer
>
> WSO2 (pvt.) Ltd.
> Colombo, Sri Lanka
> (+94) 773131798 <+94%2077%20313%201798>
>
> On Thu, Aug 31, 2017 at 10:51 AM, Sherene Mahanama <sher...@wso2.com>
> wrote:
>
>> +documentation, +shiraz, +samuel
>>
>> On Thu, Aug 31, 2017 at 10:50 AM, Sherene Mahanama <sher...@wso2.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> We can use [1] as the base URL as it will always point to the latest
>>> docs of IS. If we export an html page though, when we update the doc page
>>> with improvements the changes won't get reflected in the help page right
>>> unless we export again every time we make a change?
>>>
>>> [1] https://docs.wso2.com/identity-server
>>>
>>> Thanks,
>>> Sherene
>>>
>>> On Thu, Aug 31, 2017 at 10:38 AM, Omindu Rathnaweera <omi...@wso2.com>
>>> wrote:
>>>
>>>> One other option would be to export an html from the doc page and
>>>> include it in the product.
>>>>
>>>> On Thu, Aug 31, 2017 at 10:35 AM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Only problem I see is if Internet access is not available from the
>>>>> client's machine which can access the carbon console, which could be the
>>>>> case sometimes.
>>>>>
>>>>> On Thu, Aug 31, 2017 at 10:22 AM, Thilina Madumal <thilina...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> Currently, in IS Management Console, the context sensitive help pages
>>>>>> are outdated. See [1].
>>>>>> Even though the content is up to date, the content is not informative
>>>>>> enough IMO.
>>>>>>
>>>>>> If we are to update the help-pages, we need to make them up to date
>>>>>> and informative enough.
>>>>>> The concern is if we are to do so;
>>>>>>
>>>>>>1. The effort is significantly high
>>>>>>2. Also, it is kind of writing another set of documentation
>>>>>>
>>>>>> We already have a nice set of documentation for the Product IS.
>>>>>> Therefore shall we link the already available IS documentation to
>>>>>> Help Pages of IS Management Console? WDYT?
>>>>>>
>>>>>> [1] https://wso2.org/jira/browse/IDENTITY-446
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Thilina.
>>>>>>
>>>>>> --
>>>>>> *Thilina Madumal*
>>>>>> *Software Engineer | **WSO2*
>>>>>> Email: thilina...@wso2.com
>>>>>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>>>>>> Web:  <http://goog_716986954>http://wso2.com
>>>>>>
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>>
>>>>> *Johann Dilantha Nallathamby*
>>>>> Senior Lead Solutions Engineer
>>>>> WSO2, Inc.
>>>>> lean.enterprise.middleware
>>>>>
>>>>> Mobile - *+9476950*
>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Omindu Rathnaweera
>>>> Senior Software Engineer, WSO2 Inc.
>>>> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Sherene Mahanama
>>> Technical Writer
>>>
>>> WSO2 (pvt.) Ltd.
>>> Colombo, Sri Lanka
>>> Mobile: (+94) 777 <%28%2B94%29%20773131798>
>>> *994805*
>>>
>>
>>
>>
>> --
>> Sherene Mahanama
>> Technical Writer
>>
>> WSO2 (pvt.) Ltd.
>> Colombo, Sri Lanka
>> Mobile: (+94) 777 <%28%2B94%29%20773131798>
>> *994805*
>>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

[Johann Nallathamby]

Will it work if we have two separate attributes for the problematic
attributes like SCIM ID? If that works I guess that is one solution.

Or we need to have one listener for both SCIM 1 and SCIM2. But don't think
that's a good solution. Introduces direct coupling between two
implementations.

Regards,
Johann.

On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara  wrote:

> Hi Thilina,
>
> If we enable both SCIM1 and SCIM2 listeners at the same time two different
> SCIM IDs will be generated for the same user when adding a new user through
> SCIM. Also both SCIM1 and SCIM2 claims are mapped to the same LDAP user
> attributes. Even though both listeners get triggered only the SCIM1 ID is
> mapped to the user ID attribute. But the SCIM2 user creation response will
> contain the SCIM ID generated by SCIM2 listener.
>
> Thanks,
> Sathya
>
> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal 
> wrote:
>
>>
>> Hi all,
>>
>> While I was trying to fix IDENTITY-6315
>>  I got to know that we can't
>> enable both SCIM1 and SCIM2 at the same time in WSO2 Identity Server.
>> Is it because of this specific issue or is there any other reasons?
>>
>> Thanks & Regards,
>> Thilina.
>>
>> --
>> *Thilina Madumal*
>> *Software Engineer | **WSO2*
>> Email: thilina...@wso2.com
>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>> Web:  http://wso2.com
>>
>> 
>>
>>
>
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Shall We Link Corresponding IS Documentation as Context Sensitive Help Pages in IS Management Console?

[Johann Nallathamby]

Only problem I see is if Internet access is not available from the client's
machine which can access the carbon console, which could be the case
sometimes.

On Thu, Aug 31, 2017 at 10:22 AM, Thilina Madumal 
wrote:

> Hi Devs,
>
> Currently, in IS Management Console, the context sensitive help pages are
> outdated. See [1].
> Even though the content is up to date, the content is not informative
> enough IMO.
>
> If we are to update the help-pages, we need to make them up to date and
> informative enough.
> The concern is if we are to do so;
>
>1. The effort is significantly high
>2. Also, it is kind of writing another set of documentation
>
> We already have a nice set of documentation for the Product IS.
> Therefore shall we link the already available IS documentation to Help
> Pages of IS Management Console? WDYT?
>
> [1] https://wso2.org/jira/browse/IDENTITY-446
>
> Thanks & Regards,
> Thilina.
>
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  http://wso2.com
>
> 
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IAM] Reusing Utilities

[Johann Nallathamby]

In fix [1], we've introduced a new Util class for URI validation. We
already have a rich set of validations in [2].

Won't this help here? I think we do have URL pattern define here already.
If we don't have a pattern defined we need to improve this utility and
reuse everywhere.

I already sent a previous mail on reusing JS validation utilities in UI
layer also [3].

[1]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/commit/0db19e8602d3831d596e04c3ec68d8a35b9c840b#diff-088737b86ff1f8e078854ea4bf1e350eR31

[2]
https://github.com/wso2/carbon-identity-framework/blob/master/components/identity-core/org.wso2.carbon.identity.base/src/main/java/org/wso2/carbon/identity/base/IdentityValidationUtil.java
[3] [IAM] Can't we do the same fix by adding fragment component as a
blacklisted pattern to our JS util method?

-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is this fix correct? Can someone explain?

[Johann Nallathamby]

On Thu, Aug 24, 2017 at 3:57 AM, Isura Karunaratne <is...@wso2.com> wrote:

>
> On Thu, Aug 24, 2017 at 1:27 AM Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> https://github.com/wso2/carbon-identity-framework/commit/1f2
>> df5faf2a46258791bdaf1d4c94741626e34a1
>>
>> How is *resourceType* attribute mapped to *userType*? And why is
>> AttributeID still *mail*?
>>
>
> This is scim2 dialect. when we add a user, its resorceTyoe is user. Then
> the email address of that user becomes as user. That was the issue.
>

So isn't calling *resourceType* as *userType* wrong? We could have had the
local claim also as *resourceType*. Correct? No need to change now I think
because it may introduce migration. Better be careful in future when
mapping claims to have meaningful names and not conflict with other claims.

Another question is in SCIM2 we have multiple resource types - users,
groups and extensions. Each of these resource types can have attributes.
However in our user.core implementation we don't support resource types
other than user. So we can't properly support group resource. And we can't
have attributes for groups.

*So does it make sense to have a claim called resourceType for users?*

Because that's the only resource type we can support so why not hard code
it at the SCIM2 implementation level. At least it will avoid overhead of
mapping an additional claim. And how do we deal with group resources? Where
we do we store the resource type? Do we hard code it for groups? In that
case isn't it logical to hard code it for users as well?

Regards,
Johann.


> I think scim1 dialect uses userType claim local claim for this. remote
> dialect's attributeId is not required in new claim management module,
> instead it uses local mapped claim.
>

So are we still maintaining these attribute mappings to work with the old
claim-mgt component to be backward compatible? But even in that case I feel
we have to maintain two claim-mgt configuration files. One for the new
implementation and one for the old one. The new one can be the default. And
in our docs we can mention how we can use the old one (rename to
claim-config.xml).
Does it make sense? Otherwise the current config file is very confusing for
new users.

Regards,
Johann.


> Thanks
> Isura
>
>>
>> Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.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/
>
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] WSO2 Identity Server 5.4.0-M3 Released!

[Johann Nallathamby]

IAM Team,

Please note that the following JIRAs have not be fixed per se. According to
the comments they have been resolved as "cannot reproduce", "won't fix" or
"invalid". But the "Resolution" says "Fixed" which is incorrect. Can we
change this and make sure in future we strictly follow proper resolution
category. Otherwise this will give a wrong impression when generating stats
on public JIRAs.

[1] https://wso2.org/jira/browse/IDENTITY-5943
[2] https://wso2.org/jira/browse/IDENTITY-6126
[3] https://wso2.org/jira/browse/IDENTITY-6235
[4] https://wso2.org/jira/browse/IDENTITY-6243
[5] https://wso2.org/jira/browse/IDENTITY-6282

Regards,
Johann.

On Wed, Aug 23, 2017 at 11:03 AM, Nuwandi Wickramasinghe 
wrote:

> WSO2 Identity Server team is pleased to announce the 3rd Milestone of WSO2
>  IdentityServer 5.4.0. You can download this distribution from the
> following location.
>
> https://github.com/wso2/product-is/releases/tag/v5.4.0-m3
>
> Following list contains all the features, improvements and bug fixes
> available with this milestone.
> Patch
>
>- [IDENTITY-6206 ] - ACS
>validation failure when using signed passive saml requests
>- [IDENTITY-6208 ] -
>Possible Connection Leak in RegistryRecoveryDataStore
>
> Bug
>
>- [IDENTITY-4663 ] -
>Getting a registry indexing error while evaluating a XACML request against
>PDP
>- [IDENTITY-5549 ] -
>Backend error while creating a tenant domain with capital letters in the
>name
>- [IDENTITY-5938 ] - [NPE]
>OAuth2AuthzEndpoint has thrown exception, unwinding now
>- [IDENTITY-5943 ] -
>[LoadTest] Error while retrieving access token in Authorization Code grant
>type
>- [IDENTITY-6073 ] - OIDC
>logout fails when call back url has a uri fragment
>- [IDENTITY-6088 ] - IS
>should not return IDTokens without required claims
>- [IDENTITY-6099 ] -
>Intermittent error when invoking password reset rest api using browser
>based client
>- [IDENTITY-6117 ] -
>Observed a performance degradation due to pre-authentication and
>post-authentication event handlers
>- [IDENTITY-6126 ] - Style
>issue in IS SSO Login page in IE
>- [IDENTITY-6158 ] -
>Exception thrown when debug logs are disabled
>- [IDENTITY-6175 ] -
>Improvements for updateAppAndRevokeTokensAndAuthzCodes
>- [IDENTITY-6235 ] -
>Nullpointer Exception on Requesting Access Token twice for using a custom
>grant type.
>- [IDENTITY-6237 ] -
>PROVIDE MANDATORY DETAILS page does not go away on submit of missing cliams
>- [IDENTITY-6241 ] -
>Multiple claims mapped to a same local claim
>- [IDENTITY-6242 ] -
>Internal Server Error on Requesting Access-Token for the Same 
> 'saml2-bearer'
>- [IDENTITY-6243 ] - Error
>on requesting access tokens with federated user and primary user where both
>users have the same username.
>- [IDENTITY-6244 ] - Only
>sub is recieving even claims are set for federated users
>- [IDENTITY-6247 ] -
>Updating multiple user attributes via SCIM2 Patch-Replace does not work
>- [IDENTITY-6248 ] - ldap
>search filters with objectGUID are not working properly
>- [IDENTITY-6251 ] -
>[SCIM] ArrayIndexOutofBoundException thrown for invalid authorization
>headers
>- [IDENTITY-6254 ] -
>[SCIM] Error in user creation and retrieval after enabling the config to
>allow emails as usernames
>- [IDENTITY-6259 ] - When
>a user is created email is shown as "User"
>- [IDENTITY-6269 ] -
>sslHandshakeException in the request to /oauth2/authorize in access token
>generation
>- [IDENTITY-6271 ] -
>Users/{id} PATCH expects the "schemas" attribute to be empty
>- [IDENTITY-6273 ] -
>

[Dev] [IAM] Can't we do the same fix by adding fragment component as a blacklisted pattern to our JS util method?

[Johann Nallathamby]

Can't we do $subject to fix [1]? I thought we were following this as a
standard approach in our UI layer so that we can reuse these functionality
in all our UIs. This is the approach we were following up until IS 5.3.0.
Preventing entering fragment component could be a common requirement when
defining URLs. So there is a high chance this can be needed somewhere else.

[1]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/commit/556ec8e1c2b8ad1a8e77b9216d6a3f6b301c863b


Regards,
Johann.

-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Is this fix correct? Can someone explain?

[Johann Nallathamby]

https://github.com/wso2/carbon-identity-framework/commit/1f2df5faf2a46258791bdaf1d4c94741626e34a1

How is *resourceType* attribute mapped to *userType*? And why is
AttributeID still *mail*?

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Critical issues found in Federated OpenID Connect authenticator

[Johann Nallathamby]

IAM Team,

Following are 3 critical issues I came across with OpenID Connect when
setting up a demo for a customer. IMO all these 3 issues need to be fixed
for IS 5.4.0.
Can someone please confirm if these can be fixed for IS 5.4.0? The fixes
are quite simple.

[1] https://wso2.org/jira/browse/IDENTITY-6276
[2] https://wso2.org/jira/browse/IDENTITY-6277
[3] https://wso2.org/jira/browse/IDENTITY-6278

Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Two critical issues in IS 5.3.0 SCIM 1.1 implementation

[Johann Nallathamby]

On Wed, Aug 16, 2017 at 12:33 PM, Sathya Bandara <sat...@wso2.com> wrote:

> Hi,
>
> The issue [1] occurs due to invalid data format. It is not identified as a
> bug since as mentioned in the doc, similar to user create requests, we need
> to include json data within single quotations and not double quotations to
> avoid json parsing exceptions.With the correct format it is possible to
> include non-empty schema attributes with the request.
>
> eg:
>
> *request:*
> curl -v -k --user admin:admin -X PATCH -d '{"schemas":
> ["urn:scim:schemas:core:1.0"],"name":{"familyName": "Tester"}
> ,"userName": "hasinitg","meta": {"attributes": []}}' --header
> "Content-Type:application/json" https://localhost:9443/wso2/
> scim/Users/15722a71-3bd1-4864-8460-1e63a2dace65
>
> *response:*
>
> {"emails":[{"type":"home","value":"hasini_home.com"},{"
> type":"work","value":"hasini_work.com"}],"meta":{"created":
> "2017-08-16T10:07:36","location":"https://localhost:
> 9443/wso2/scim/Users/15722a71-3bd1-4864-8460-1e63a2dace65","
> lastModified":"2017-08-16T12:17:11"},"schemas":["urn:scim:
> schemas:core:1.0"],"name":{"familyName":"Tester","
> givenName":"hasinitg"},"id":"15722a71-3bd1-4864-8460-
> 1e63a2dace65","userName":"hasinitg"}
>

This seems a bit weird to me. If it's a JSON parsing problem then double
quotes should not work for any kind of data JSON data. How come it is
working for empty array?

Is this double quote problem something related to how curl works? If we use
a HTTP client don't we have this issue? If it's a curl problem then we
shouldn't worry I suppose.

Regards,
Johann.


> [1] https://wso2.org/jira/browse/IDENTITY-6271
>
> Thanks,
> Sathya
>
> On Wed, Aug 16, 2017 at 11:37 AM, Gayan Gunawardana <ga...@wso2.com>
> wrote:
>
>>
>>
>> On Tue, Aug 15, 2017 at 10:44 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> IAM Team,
>>>
>>> I found below two critical issues in IS 5.3.0 SCIM 1.1 implementation.
>>>
>>> 1. Users/{id} PATCH operation expects the "schemas" attribute to be
>>> empty. If the core schema value is given it throws an error [1].
>>>
>>> 2. "userName" attribute is mandatory in Users/{id} PATCH operation. This
>>> is not the case according to the spec [2].
>>>
>>> I think the first issue is a MUST fix. Because all the users who will
>>> try our SCIM patch implementation will face this issue and discontinue
>>> trying/using WSO2 IS 5.3.0. So I think this must be fixed.
>>>
>> Yes we have to look at fixing this issue in backward-compatible manner.
>>
>>>
>>> The second issue seems to be a problem with our implementation design. I
>>> don't know if this could be easily fixed. May be it can be fixed at the
>>> cost of performance. Someone has to check on this. But if that is the case
>>> what is going to be our stance here? Compliance vs. Performance. Which side
>>> do we take? I would say compliance is more important. What are your
>>> thoughts?
>>>
>> We can fix this issue as well but need to check for API changes.
>>
>>>
>>> [1] https://wso2.org/jira/browse/IDENTITY-6271
>>> [2] https://wso2.org/jira/browse/IDENTITY-6272
>>>
>>> Thanks & Regards,
>>> Johann.
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

[Dev] Two critical issues in IS 5.3.0 SCIM 1.1 implementation

[Johann Nallathamby]

IAM Team,

I found below two critical issues in IS 5.3.0 SCIM 1.1 implementation.

1. Users/{id} PATCH operation expects the "schemas" attribute to be empty.
If the core schema value is given it throws an error [1].

2. "userName" attribute is mandatory in Users/{id} PATCH operation. This is
not the case according to the spec [2].

I think the first issue is a MUST fix. Because all the users who will try
our SCIM patch implementation will face this issue and discontinue
trying/using WSO2 IS 5.3.0. So I think this must be fixed.

The second issue seems to be a problem with our implementation design. I
don't know if this could be easily fixed. May be it can be fixed at the
cost of performance. Someone has to check on this. But if that is the case
what is going to be our stance here? Compliance vs. Performance. Which side
do we take? I would say compliance is more important. What are your
thoughts?

[1] https://wso2.org/jira/browse/IDENTITY-6271
[2] https://wso2.org/jira/browse/IDENTITY-6272

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Deploying multiple travelocity applications by renaming the web application name

[Johann Nallathamby]

Provided a fix for this issue: https://github.com/wso2/product-is/pull/1303.
Please review and merge.

On Sun, Aug 13, 2017 at 1:33 AM, Harsha Kumara  wrote:

> Created JIRA in [1] in a case of we going to add it.
>
>  https://wso2.org/jira/browse/IDENTITY-6257
>
> On Sun, Aug 13, 2017 at 1:31 AM, Harsha Kumara  wrote:
>
>> Hi All,
>>
>> I tried to deploy multiple travelocity applications samples by renaming
>> the web application directory. But it didn't work. The reason for this
>> behavior is in code level we check the web application context path
>> contains travelocity.com. So if I renamed the web application to
>> travelovitysample.com, it won't work as the initial travelocity.property
>> configuration not getting loaded. I think it's better to add this.
>>
>> Code :
>>
>> if(servletContextEvent.getServletContext().getContextPath().contains("travelocity.com"))
>>  {
>> properties.load(servletContextEvent.getServletContext().
>> getResourceAsStream("/WEB-INF/classes/travelocity.properties"));
>> } else 
>> if(servletContextEvent.getServletContext().getContextPath().contains("avis.com"))
>>  {
>> properties.load(servletContextEvent.getServletContext().
>> getResourceAsStream("/WEB-INF/classes/avis.properties"));
>> }
>>
>> Then I have added an else statement which will switch to
>> travelocity.properties file in its own web application path.
>>
>> if(servletContextEvent.getServletContext().getContextPath().contains("travelocity.com"))
>>  {
>> properties.load(servletContextEvent.getServletContext().
>> getResourceAsStream("/WEB-INF/classes/travelocity.properties"));
>> } else 
>> if(servletContextEvent.getServletContext().getContextPath().contains("avis.com"))
>>  {
>> properties.load(servletContextEvent.getServletContext().
>> getResourceAsStream("/WEB-INF/classes/avis.properties"));
>> } else {
>> try {
>> properties.load(servletContextEvent.getServletContext().
>> 
>> getResourceAsStream("/WEB-INF/classes/travelocity.properties"));
>> } catch (Exception e) {
>> LOGGER.log(Level.SEVERE, "Error while loading the default 
>> configuration in /WEB-INF/classes/travelocity.properties", e);
>> }
>> }
>>
>> Thanks,
>> Harsha
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <+94%2077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Supporting attributes feature for SCIM filtering

[Johann Nallathamby]

On Wed, Aug 2, 2017 at 2:30 PM, Pulasthi Mahawithana <pulast...@wso2.com>
wrote:

> Hi Johann,
>
> Both the "attributes" and "filter" can be used together in IS 5.3.0.
> Please see the last example at [1].
>

Oh great! Now I am trying to remember where I got this problem originally
from :). Will check.


>
> [1] https://medium.com/@pulasthi7/scim-list-users-
> with-given-attributes-in-wso2-identity-server-5-3-0-8360522d3ea9
>

> On Wed, Aug 2, 2017 at 2:10 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi Chamila,
>>
>> On Wed, Aug 2, 2017 at 2:06 PM, Chamila Wijayarathna <
>> cdwijayarat...@gmail.com> wrote:
>>
>>> Hi Johann,
>>>
>>> Sorry for the confusion, I didn't knew about SCIM attributes
>>> implementation previously. Is this only available for SCIM 2.0 or is this
>>> available in SCIM 1.x implementation as well?
>>>
>>
>> This is there from IS 5.3.0 onwards.
>>
>>
>>>
>>> If it is supported in SCIM list, it should be there in filter also.
>>> Because AFAIK, filter is parameter we pass to list operation. Filter is not
>>> a different operation from list. If I explain it more, what we refer as
>>> filter is a overloaded function of list.
>>>
>>
>> Exactly.
>>
>>
>>>
>>> eg : User List();
>>> User List (String filter);
>>>
>>> So filter operation should return a same type of objects, but may be a
>>> less number. If they behave differently, IMO it is wrong.
>>>
>>> So +1 for implementing attributes here as well.
>>>
>>
>> Thanks for your feedback.
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> Regards!
>>> Chamila
>>>
>>> On Wed, Aug 2, 2017 at 6:23 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 11, 2017 at 6:52 PM, Chamila Wijayarathna <
>>>> cdwijayarat...@gmail.com> wrote:
>>>>
>>>>> Hi Johann,
>>>>>
>>>>> In IS 5.0
>>>>> filter=username eq name
>>>>> gave the result that you are expecting here, but we changed it to
>>>>> return only meta data since retrieving all attributes is costly. Spec also
>>>>> mentions that query should minimally return meta data, returning 
>>>>> additional
>>>>> data or all data is also compliant with the spec IIRC.
>>>>>
>>>>
>>>> Correct.
>>>>
>>>>
>>>>>
>>>>> So in my opinion, what you are suggesting here is moving back to the
>>>>> old functionality we had and I believe if we are to do that, we will have
>>>>> to do that at the cost of performance. I suppose this may not as costly as
>>>>> 2 network calls if filter returns only 1 result. But it is not guaranteed
>>>>> in filter or attribute thing you are suggesting that it will return only 1
>>>>> result, so still performance can be a issue.
>>>>>
>>>>
>>>> No. I am not saying to move back to old implementation. I am saying to
>>>> implement "attributes" feature to SCIM filtering also. Currently we have it
>>>> only for SCIM listing. So if we implement that, by default filtering will
>>>> return only metadata. And if needed extra attributes, we can specifically
>>>> request like in SCIM listing.
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>>
>>>>>
>>>>> Cheers
>>>>> Chamila
>>>>>
>>>>> On Tue, Jul 11, 2017 at 11:08 PM, Johann Nallathamby <joh...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi IAM Team,
>>>>>>
>>>>>> Can we support "attributes" feature for SCIM filter query? Right now
>>>>>> SCIM filter query returns only metadata. It doesn't return additional
>>>>>> attributes. Therefore we have to do at least two network calls if we need
>>>>>> to get user's attributes using username. Can we do this in one call 
>>>>>> network
>>>>>> call?
>>>>>>
>>>>>> "attributes" feature for /Users GET allows to retrieve any number of
>>>>>> additional attributes we want apart from the metadata. Thi

Re: [Dev] Supporting attributes feature for SCIM filtering

[Johann Nallathamby]

Hi Chamila,

On Wed, Aug 2, 2017 at 2:06 PM, Chamila Wijayarathna <
cdwijayarat...@gmail.com> wrote:

> Hi Johann,
>
> Sorry for the confusion, I didn't knew about SCIM attributes
> implementation previously. Is this only available for SCIM 2.0 or is this
> available in SCIM 1.x implementation as well?
>

This is there from IS 5.3.0 onwards.


>
> If it is supported in SCIM list, it should be there in filter also.
> Because AFAIK, filter is parameter we pass to list operation. Filter is not
> a different operation from list. If I explain it more, what we refer as
> filter is a overloaded function of list.
>

Exactly.


>
> eg : User List();
> User List (String filter);
>
> So filter operation should return a same type of objects, but may be a
> less number. If they behave differently, IMO it is wrong.
>
> So +1 for implementing attributes here as well.
>

Thanks for your feedback.

Regards,
Johann.


>
> Regards!
> Chamila
>
> On Wed, Aug 2, 2017 at 6:23 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>>
>>
>> On Tue, Jul 11, 2017 at 6:52 PM, Chamila Wijayarathna <
>> cdwijayarat...@gmail.com> wrote:
>>
>>> Hi Johann,
>>>
>>> In IS 5.0
>>> filter=username eq name
>>> gave the result that you are expecting here, but we changed it to return
>>> only meta data since retrieving all attributes is costly. Spec also
>>> mentions that query should minimally return meta data, returning additional
>>> data or all data is also compliant with the spec IIRC.
>>>
>>
>> Correct.
>>
>>
>>>
>>> So in my opinion, what you are suggesting here is moving back to the old
>>> functionality we had and I believe if we are to do that, we will have to do
>>> that at the cost of performance. I suppose this may not as costly as 2
>>> network calls if filter returns only 1 result. But it is not guaranteed in
>>> filter or attribute thing you are suggesting that it will return only 1
>>> result, so still performance can be a issue.
>>>
>>
>> No. I am not saying to move back to old implementation. I am saying to
>> implement "attributes" feature to SCIM filtering also. Currently we have it
>> only for SCIM listing. So if we implement that, by default filtering will
>> return only metadata. And if needed extra attributes, we can specifically
>> request like in SCIM listing.
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> Cheers
>>> Chamila
>>>
>>> On Tue, Jul 11, 2017 at 11:08 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> Hi IAM Team,
>>>>
>>>> Can we support "attributes" feature for SCIM filter query? Right now
>>>> SCIM filter query returns only metadata. It doesn't return additional
>>>> attributes. Therefore we have to do at least two network calls if we need
>>>> to get user's attributes using username. Can we do this in one call network
>>>> call?
>>>>
>>>> "attributes" feature for /Users GET allows to retrieve any number of
>>>> additional attributes we want apart from the metadata. This is very
>>>> convenient to avoid too many network calls. If the same is available for
>>>> SCIM filter query it will be great I think.
>>>>
>>>> I checked the spec but couldn't find anything. Spec seems to be silent
>>>> on it. Any expert opinion on this subject?
>>>>
>>>> Regards,
>>>> Johann.
>>>>
>>>> --
>>>>
>>>> *Johann Dilantha Nallathamby*
>>>> Senior Lead Solutions Engineer
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - *+9476950*
>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Chamila Dilshan Wijayarathna,
>>> PhD Research Student
>>> The University of New South Wales (UNSW Canberra)
>>> Australian Centre for Cyber Security
>>> Australian Defence Force Academy
>>> PO Box 7916, Canberra BA ACT 2610
>>> Australia
>>> Mobile:(+61)416895795 <+61%20416%20895%20795>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
> Chamila Dilshan Wijayarathna,
> PhD Research Student
> The University of New South Wales (UNSW Canberra)
> Australian Centre for Cyber Security
> Australian Defence Force Academy
> PO Box 7916, Canberra BA ACT 2610
> Australia
> Mobile:(+61)416895795 <+61%20416%20895%20795>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] Supporting attributes feature for SCIM filtering

[Johann Nallathamby]

On Tue, Jul 11, 2017 at 6:52 PM, Chamila Wijayarathna <
cdwijayarat...@gmail.com> wrote:

> Hi Johann,
>
> In IS 5.0
> filter=username eq name
> gave the result that you are expecting here, but we changed it to return
> only meta data since retrieving all attributes is costly. Spec also
> mentions that query should minimally return meta data, returning additional
> data or all data is also compliant with the spec IIRC.
>

Correct.


>
> So in my opinion, what you are suggesting here is moving back to the old
> functionality we had and I believe if we are to do that, we will have to do
> that at the cost of performance. I suppose this may not as costly as 2
> network calls if filter returns only 1 result. But it is not guaranteed in
> filter or attribute thing you are suggesting that it will return only 1
> result, so still performance can be a issue.
>

No. I am not saying to move back to old implementation. I am saying to
implement "attributes" feature to SCIM filtering also. Currently we have it
only for SCIM listing. So if we implement that, by default filtering will
return only metadata. And if needed extra attributes, we can specifically
request like in SCIM listing.

Regards,
Johann.


>
> Cheers
> Chamila
>
> On Tue, Jul 11, 2017 at 11:08 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Hi IAM Team,
>>
>> Can we support "attributes" feature for SCIM filter query? Right now SCIM
>> filter query returns only metadata. It doesn't return additional
>> attributes. Therefore we have to do at least two network calls if we need
>> to get user's attributes using username. Can we do this in one call network
>> call?
>>
>> "attributes" feature for /Users GET allows to retrieve any number of
>> additional attributes we want apart from the metadata. This is very
>> convenient to avoid too many network calls. If the same is available for
>> SCIM filter query it will be great I think.
>>
>> I checked the spec but couldn't find anything. Spec seems to be silent on
>> it. Any expert opinion on this subject?
>>
>> Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Chamila Dilshan Wijayarathna,
> PhD Research Student
> The University of New South Wales (UNSW Canberra)
> Australian Centre for Cyber Security
> Australian Defence Force Academy
> PO Box 7916, Canberra BA ACT 2610
> Australia
> Mobile:(+61)416895795 <+61%20416%20895%20795>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

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

Re: [Dev] JDBCUserstore Config "IsEmailUserName"

[Johann Nallathamby]

I have also seen this and feel it's redundant. If there is no real purpose
for this can we  deprecate it and remove any usage of this property? If it
allows control per user store, then EnableEmailUserName is redundant in
carbon.xml.

Thoughts?

On Tue, Aug 1, 2017 at 12:33 AM, Hasintha Indrajee 
wrote:

> Is there any usage of subject ?. If so any idea where we honor this config
> element ? Docs do have this [1]
>
> [1] https://docs.wso2.com/display/IS530/Configuring+a+JDBC+User+Store
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev