Re: [Architecture] Dropping Unregistered Scope(s) from OAuth Request in IS.

[Asela Pathberiya]

On Thu, Feb 13, 2020 at 11:15 AM Sarubi Thillainathan 
wrote:

>
>
> On Thu, Feb 13, 2020 at 10:50 AM Asela Pathberiya  wrote:
>
>>
>>
>> On Thu, Feb 13, 2020 at 10:48 AM Sarubi Thillainathan 
>> wrote:
>>
>>> Hi Asela,
>>>
>>> Just to be clear,  Can we register scope values as regex patterns ?
>>>> In APIM there is scope white listing capabilities which can be sent any
>>>> scope value related to the given regex, "device_*"  such scope.
>>>>
>>> Nope, in IS we don't have this capability.
>>> The only thing that we enforce is can't have space in the scope name.
>>>
>>
>> There are cases in which application needs to send some random scope to
>> identify the devices.  Can't we handle such cases by default ?
>>
> Yes, we can't handle such cases default. I would like to know why those
> needs to be random? If it is for identifying the device then can't we
> register those beforehand?
>

Just thought of similar to this [1] as we are not supporting multiple
access token for given user/application

[1]
https://apim.docs.wso2.com/en/3.0.0/Learn/APISecurity/OAuth2/OAuth2Scopes/scope-whitelisting/


>
>
>>
>>
> Thanks,
>> Asela.
>>
>>
>>> Thanks,
>>> Sarubi.
>>>
>>> On Wed, Feb 12, 2020 at 6:06 PM Asela Pathberiya  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 12, 2020 at 5:44 PM Sarubi Thillainathan 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 12, 2020 at 5:38 PM Sarubi Thillainathan 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Currently in IS, whenever a token request comes with a list of scopes
>>>>>> we'll be showing all the scopes and get the consent from the user
>>>>>> regardless of that scopes are requested or not in the Identity Server.
>>>>>> But by going forward with IS 5.10.0, we'll be more descriptive and
>>>>>> decided to show the display name of the scope and it's the description as
>>>>>> well when we are getting the consent from the user. Also, if the scope is
>>>>>> not registered under the OAuth2 scope or OIDC scope in the IS, then we
>>>>>> decided to skip that particular scope from the consent page also in the
>>>>>> response as a default behaviour.
>>>>>>
>>>>>
>>>> Just to be clear,  Can we register scope values as regex patterns ?
>>>> In APIM there is scope white listing capabilities which can be sent any
>>>> scope value related to the given regex, "device_*"  such scope.
>>>>
>>>> Thanks,
>>>> Asela.
>>>>
>>>>
>>>>>
>>>>>> In order to keep the backward compatibility, we'll keep a flag so
>>>>>> that we can enable it if we want to list the scope which is not 
>>>>>> registered.
>>>>>> Note that in that case scopes which are not registered will display with
>>>>>> the provided scope name and scopes which are registered will displayed 
>>>>>> with
>>>>>> their corresponding display name and description in the consent page.
>>>>>>
>>>>>> Highly appreciate your ideas and suggestion on this.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Sarubi.
>>>>>> --
>>>>>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>>>>>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>>>>>
>>>>>> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>>>>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>>>>
>>>>> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards,
>>>> Asela
>>>>
>>>> Mobile : +94 777 625 933
>>>>
>>>> http://soasecurity.org/
>>>> http://xacmlinfo.org/
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>>
>>> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
> --
> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>
> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Dropping Unregistered Scope(s) from OAuth Request in IS.

[Asela Pathberiya]

On Thu, Feb 13, 2020 at 10:48 AM Sarubi Thillainathan 
wrote:

> Hi Asela,
>
> Just to be clear,  Can we register scope values as regex patterns ?
>> In APIM there is scope white listing capabilities which can be sent any
>> scope value related to the given regex, "device_*"  such scope.
>>
> Nope, in IS we don't have this capability.
> The only thing that we enforce is can't have space in the scope name.
>

There are cases in which application needs to send some random scope to
identify the devices.  Can't we handle such cases by default ?

Thanks,
Asela.


> Thanks,
> Sarubi.
>
> On Wed, Feb 12, 2020 at 6:06 PM Asela Pathberiya  wrote:
>
>>
>>
>> On Wed, Feb 12, 2020 at 5:44 PM Sarubi Thillainathan 
>> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Feb 12, 2020 at 5:38 PM Sarubi Thillainathan 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Currently in IS, whenever a token request comes with a list of scopes
>>>> we'll be showing all the scopes and get the consent from the user
>>>> regardless of that scopes are requested or not in the Identity Server.
>>>> But by going forward with IS 5.10.0, we'll be more descriptive and
>>>> decided to show the display name of the scope and it's the description as
>>>> well when we are getting the consent from the user. Also, if the scope is
>>>> not registered under the OAuth2 scope or OIDC scope in the IS, then we
>>>> decided to skip that particular scope from the consent page also in the
>>>> response as a default behaviour.
>>>>
>>>
>> Just to be clear,  Can we register scope values as regex patterns ?
>> In APIM there is scope white listing capabilities which can be sent any
>> scope value related to the given regex, "device_*"  such scope.
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>> In order to keep the backward compatibility, we'll keep a flag so that
>>>> we can enable it if we want to list the scope which is not registered. Note
>>>> that in that case scopes which are not registered will display with the
>>>> provided scope name and scopes which are registered will displayed with
>>>> their corresponding display name and description in the consent page.
>>>>
>>>> Highly appreciate your ideas and suggestion on this.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Sarubi.
>>>> --
>>>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>>>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>>>
>>>> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>>>>
>>>
>>>
>>> --
>>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>>
>>> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>
> *[image: https://wso2.com/signature] <https://wso2.com/signature>*
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Dropping Unregistered Scope(s) from OAuth Request in IS.

[Asela Pathberiya]

On Wed, Feb 12, 2020 at 5:44 PM Sarubi Thillainathan 
wrote:

>
>
>
> On Wed, Feb 12, 2020 at 5:38 PM Sarubi Thillainathan 
> wrote:
>
>> Hi All,
>>
>> Currently in IS, whenever a token request comes with a list of scopes
>> we'll be showing all the scopes and get the consent from the user
>> regardless of that scopes are requested or not in the Identity Server.
>> But by going forward with IS 5.10.0, we'll be more descriptive and
>> decided to show the display name of the scope and it's the description as
>> well when we are getting the consent from the user. Also, if the scope is
>> not registered under the OAuth2 scope or OIDC scope in the IS, then we
>> decided to skip that particular scope from the consent page also in the
>> response as a default behaviour.
>>
>
Just to be clear,  Can we register scope values as regex patterns ?
In APIM there is scope white listing capabilities which can be sent any
scope value related to the given regex, "device_*"  such scope.

Thanks,
Asela.


>
>> In order to keep the backward compatibility, we'll keep a flag so that we
>> can enable it if we want to list the scope which is not registered. Note
>> that in that case scopes which are not registered will display with the
>> provided scope name and scopes which are registered will displayed with
>> their corresponding display name and description in the consent page.
>>
>> Highly appreciate your ideas and suggestion on this.
>>
>>
>>
>>
>> Thanks,
>> Sarubi.
>> --
>> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
>> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>>
>> *[image: https://wso2.com/signature] *
>>
>
>
> --
> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc.
> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com
>
> *[image: https://wso2.com/signature] *
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Improvements to session data persistence - Identity Server

[Asela Pathberiya]

On Wed, Jan 1, 2020 at 8:43 PM Asela Pathberiya  wrote:

>
>
> On Tue, Dec 31, 2019 at 6:36 PM Supun Perera  wrote:
>
>> Hi All,
>>
>> *Problem*
>> As of now Identity server users database based session data persistence
>> for storing the user authentication sessions in addition to the
>> authentication cache. Also, it's recommended to enable the session
>> persistence to the database due to the limitation of the cache size
>> available and the distributed caching issues faced with hazelcast.
>> Even though the database based session persistence solution is working
>> fine for many customers who have relatively low user sessions created, It's
>> not the case for some other customers who have the use cases such as having
>> many user logging on a burst. As an example, students log in on an exam
>> portal.
>>
>> In such cases what we have seen is that the growth of the session table
>> (IDN_AUTH_SESSION_STORE) would be huge. Even though there are clean up
>> stored procedures introduce to maintain this table in such cases, it's not
>> that efficient as the
>> 1. Clean up procedure will not capture this data until the
>> session expires time.
>> 2. Even though the cleanup procedure captured and delete the data, it
>> will not immediately reclaim the disk space from the database.
>> 3. Meantime the session data table could be grown to a level ( 200+ GB )
>> which will slow down the entire login process.
>>
>> *Solution*
>> 1. Reduce the session object size. (one of the major issues is that the
>> session object that we will be storing is quite big for a single record.)
>> Even if we are going for in a memory-based solution (such as Redis). This
>> need to be addressed prior to that. Since the problem will be remaining
>> even with an in-memory based solution if the session object we going to
>> store is quite huge. Also reducing this would absolutely help to improve
>> the performance of the database based solution as well. Therefore we need
>> to revisit the implementation and optimise this to reduce the session
>> object size in the first place.
>>
>
> This is  a good point to investigate.  I guess we need to verify on
> duplicates + serialization method which is used by default. Can we invest
> time on this ?
>
>
>>
>> 2. The implementation of the session data store should not be limited to
>> storing with a database-based solution, Rather we should provide an
>> extensible interface so that could extend and customise the implementation
>> to plug solutions like Redis, NoSQL databases or any other in-memory
>> solutions based on customer preference and our recommendation.
>> With this, we could ship the product with the default behaviour of
>> storing the session data into the database. However, if the customer is
>> willing to change the default behaviour for better performance we could
>> provide that flexibility out of the box. This something already pointed in
>> the issue [1] as well. however, I guess we need to pay more attention to
>> this and prioritise this as this would be one of the major pain points that
>> we could see from the customers.
>>
>
> +1  This also would help to override any plugable serialization way as
> well based on the user cases.  It would be great if we can have such
> interface in future WSO2IS release.
>

@Supun PereraAs discussed offline,  Shall we invest
some time to check on this  ?

Thanks,
Asela.


>
> Also; if customers  prefer to work on without session persistence (if
> remember me & SSO timeout are not a major concern)  we can come up with
> simple equation based factor such as   idle timeout + number of active
> users + session object size + optimal memory +  session cache capacity to
> decide whether it can be operate optimally without persistence.
>
> Thanks,
> Asela.
>
>>
>> [1] https://github.com/wso2/product-is/issues/4355
>>
>>
>> *Supun Perera | **Senior Software Engineer*
>> (e) supu...@wso2.com |  (m) +94712235101 | (w) wso2.com
>> <https://www.wso2.com>
>> <http://wso2.com/signature>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> Mobile : +94 777 625 933
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Improvements to session data persistence - Identity Server

[Asela Pathberiya]

On Tue, Dec 31, 2019 at 6:36 PM Supun Perera  wrote:

> Hi All,
>
> *Problem*
> As of now Identity server users database based session data persistence
> for storing the user authentication sessions in addition to the
> authentication cache. Also, it's recommended to enable the session
> persistence to the database due to the limitation of the cache size
> available and the distributed caching issues faced with hazelcast.
> Even though the database based session persistence solution is working
> fine for many customers who have relatively low user sessions created, It's
> not the case for some other customers who have the use cases such as having
> many user logging on a burst. As an example, students log in on an exam
> portal.
>
> In such cases what we have seen is that the growth of the session table
> (IDN_AUTH_SESSION_STORE) would be huge. Even though there are clean up
> stored procedures introduce to maintain this table in such cases, it's not
> that efficient as the
> 1. Clean up procedure will not capture this data until the session expires
> time.
> 2. Even though the cleanup procedure captured and delete the data, it will
> not immediately reclaim the disk space from the database.
> 3. Meantime the session data table could be grown to a level ( 200+ GB )
> which will slow down the entire login process.
>
> *Solution*
> 1. Reduce the session object size. (one of the major issues is that the
> session object that we will be storing is quite big for a single record.)
> Even if we are going for in a memory-based solution (such as Redis). This
> need to be addressed prior to that. Since the problem will be remaining
> even with an in-memory based solution if the session object we going to
> store is quite huge. Also reducing this would absolutely help to improve
> the performance of the database based solution as well. Therefore we need
> to revisit the implementation and optimise this to reduce the session
> object size in the first place.
>

This is  a good point to investigate.  I guess we need to verify on
duplicates + serialization method which is used by default. Can we invest
time on this ?


>
> 2. The implementation of the session data store should not be limited to
> storing with a database-based solution, Rather we should provide an
> extensible interface so that could extend and customise the implementation
> to plug solutions like Redis, NoSQL databases or any other in-memory
> solutions based on customer preference and our recommendation.
> With this, we could ship the product with the default behaviour of storing
> the session data into the database. However, if the customer is willing to
> change the default behaviour for better performance we could provide that
> flexibility out of the box. This something already pointed in the issue [1]
> as well. however, I guess we need to pay more attention to this and
> prioritise this as this would be one of the major pain points that we could
> see from the customers.
>

+1  This also would help to override any plugable serialization way as well
based on the user cases.  It would be great if we can have such interface
in future WSO2IS release.

Also; if customers  prefer to work on without session persistence (if
remember me & SSO timeout are not a major concern)  we can come up with
simple equation based factor such as   idle timeout + number of active
users + session object size + optimal memory +  session cache capacity to
decide whether it can be operate optimally without persistence.

Thanks,
Asela.

>
> [1] https://github.com/wso2/product-is/issues/4355
>
>
> *Supun Perera | **Senior Software Engineer*
> (e) supu...@wso2.com |  (m) +94712235101 | (w) wso2.com
> 
> 
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Few improvements for the wonderful feature > Correlation Logs

[Asela Pathberiya]

On Tue, Oct 22, 2019 at 10:12 PM Supun Perera  wrote:

> Reduced Audience
>
>
>
> On Tue, Oct 22, 2019 at 9:03 PM Supun Perera  wrote:
>
>> Hi All,
>>
>> As the correlation logs is a wonderful feature for troubleshooting the
>> issues, It was very helpful in support, However, we have noticed that it
>> could be made better if we could enable the same in the server runtime
>> rather doing the server restart to apply the same. Hence we believe that it
>> would be really great if we could implement a mechanism to *enable and
>> disable the correlation logs in run time*.
>>
>> Further, we have noticed that we could improve the logging events details
>> more with the following 4 items. which we believe is certainly required for
>> drill down the issues further.
>>
>> 1. Work on a mechanism to enable and disable the correlation logs in
>> runtime without server downtime.
>>
>
Shall we provide an admin API to enable this as developers need to enable
this to verify the applications behavior ?

Thanks
Asela.


> 2. Print the Get connection / Close connection time taken (database, LDAP)
>> in the correlation logs.
>> 3. Print the records iteration (if the LDAP or Database returns many
>> records, the time taken for the record iteration is not visible.) - While
>> investigating the same we have noticed that each iteration completed with a
>> network call as well.
>> 4. Print the missing details in between two correlation log event (some
>> correlation logs we could notice that the LDAP/ DATABASE query has returned
>> within *1 - 2 ms*, however the next line of the correlation log prints
>> after several *seconds*. Further investigating the same could notice
>> that some of them are caused by triggering event listens. Hence, it would
>> be easy to track it further if we could print the correlation ID along with
>> the debug/info logs for each component.)
>>
>> *Supun Perera*
>> *Senior Software Engineer | WSO2*
>>
>> Email   : supu...@wso2.com
>> Mobile  : +94712235101
>> Web : http://wso2.com
>>
>> 
>>
>>

-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [APIM] Mutual SSL with Load Balancer

[Asela Pathberiya]

On Wed, Sep 25, 2019 at 10:47 AM gayan gunawardana 
wrote:

> Hi APIM team,
>
> Is there any recommended deployment pattern to implement [1] if SSL
> termination happen from load balancer ?
>

One option is that sending the client certificate's data using HTTP
header.  Also it can be done at the SSL termination point as it has access
to the client certificate.

I assume that we have implemented such sample handler to GW.

Thanks,
Asela.


>
> [1] https://docs.wso2.com/display/AM260/Securing+APIs+with+Mutual+SSL
>
> --
> Gayan
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Step up authentication for accessing high value resources/transactions

[Asela Pathberiya]

On Wed, Sep 18, 2019 at 7:09 AM Ruwan Abeykoon  wrote:

> Hi Nipun,
> This is supported OOTB [1]
>
> [1] https://docs.wso2.com/display/IS570/Working+with+ACR+and+AMR
>

Does this support with back channel authentication + token granting ?

Thanks
Asela.


>
> Cheers,
> Ruwan A
>
> On Wed, Sep 18, 2019 at 12:44 AM Nipun Thathsara  wrote:
>
>> Hello Everyone,
>>
>> *Use case :*
>> An Oauth application supports accessing both high value and low value
>> resources. Say these resources are protected with two types of scopes as
>> highValueScope and lowValueScope respectively. User can obtain an access
>> token for the lowValueScope with just basic authentication and continue
>> accessing low value resources (Balance between security and the user
>> experience). Whenever the user decides to access a higher value resource
>> (or maybe perform a high value transaction), they indeed need to obtain
>> another access token with the highValueScope. As the name implies, this
>> scope requires a step-up authentication (OTP maybe). Thereafter, the user
>> is free to access either resource.
>>
>> *Practical scenario :*
>> Banking system requesting higher levels of authentication upon performing
>> a transaction worth over 1 million.
>>
>> *Catering this with a custom grant : *
>> First token would be obtained by providing the user credentials (code
>> grant). Once the step-up authentication (SMS OTP here) is triggered, this
>> would be handled by a custom grant which accepts a Bearer token (previously
>> obtained) and issues/validates sms otp for the user. Upon a  successful
>> verification only, the second access token will be issued to the
>> application.
>>
>> *Suggestion :*
>> Believe that this is a common use case and the WSO2 Identity Server
>> should be addressing this OOTB rather than going for customizations. Which
>> will enable users to easily adopt any kind of authenticator we support as
>> their step-up option and make the process seamless as much as possible.
>>
>> Appreciate your thoughts.
>>
>> Cheers,
>> --
>>
>> *Nipun Thathsara*
>> Software Engineer | WSO2
>>
>> Email : nip...@wso2.com
>> Mobile : +94713031875
>> Web : http://wso2.com
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
> (w) +947435800  | Email: ruw...@wso2.com
>
>

-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] Making self-contained access tokens the default in APIM 3.0

[Asela Pathberiya]

On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias  wrote:

> Hi,
>
> With the introduction of the Microgateway self-contained access tokens
> were supported in the API Manager since version 2.5. Self-contained access
> tokens however were only supported in the Microgateway so far. The regular
> gateway was unable to process and validate a self-contained access token.
> With API Manager 3.0 we are bringing this support to the regular gateway as
> well. With this we hope to make self-contained tokens the default token
> type of applications. Opaque tokens will still be supported as before.
> There are several benefits of using self-contained access tokens. These are,
>
> 1) The gateway no longer connects to the Key Manager when processing API
> requests. This makes the deployment simpler and reduces configuration
> points a bit.
> 2) We no longer have to scale the Key Manager when we need the Gateway to
> be scaled. This bring a significant reduction to the cost of using the
> product in larger deployments.
> 3) The gateway becomes regionally resilient. A token issued from one
> region can be validated by a gateway in another region even if the data is
> not synced.
> 4) Back-end JWTs will be included in as part of the access token itself
> (self-contained). This eliminates the need of creating back-end JWTs while
> the API request is being processed. Which in turn makes APIs calls much
> faster.
>
> One pending items that's left to handle is the revocation of
> self-contained access tokens. Since the gateway does not connect to the Key
> Manager for validating self-contained tokens, the gateway will not know
> when a particular token has been revoked. Using shorter expiry times for
> access token addresses this solution to a certain extent. We hope to
> implement the same solution we implemented for the Microgateway to address
> this. The Key Manager will be notifying the gateway cluster through a
> broker when a token has been revoked. And the gateway will no longer be
> treating the particular token as valid upon receiving the notification.
>
> Appreciate your thoughts and suggestions on this.
>

So we are making it as default to increase the usage of it ?

Is this would be same for developer token in store (application tokens)?
What are the default user details which are adding to self-contains access
token ?

Thanks,
Asela.


>
> Thanks,
> NuwanD.
> --
> *Nuwan Dias* | Director | WSO2 Inc.
> (m) +94 777 775 729 | (e) nuw...@wso2.com
> [image: Signature.jpg]
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] SAML SP certificate expiry validation

[Asela Pathberiya]

On Thu, Jul 18, 2019 at 1:55 PM Dinali Dabarera  wrote:

> Hi all,
>
> As an improvement, we have introduced a new validation for  SP certificate
> expiry time in SAML request validation flow flow as a fix for the issue
> reported in [1]. The fix is as follows [2]
>
> We have introduced a new property called
> ** in the identity.xml file
> under .
>
> In the master implementation, we thought of keeping it as false by
> default, because there is a possibility that some users may use expired
> certificates for their service provider which we can not restrict.
>

+1   As certificate has been configured explicitly.


> If any client wants to validate the SP certificate expiry time, they can
> make this * *property to "true"
> and enable this certificate expiry validation.
>
> Your feedback on this is highly appreciated, if there is any concerns.
>

Are we fixing SAML2 Bear grant  +  Outbound SAML response ?

 Thanks,
Asela.

>
> [1] https://github.com/wso2/product-is/issues/5883
> [2] https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/236
> and https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/237
> and https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/239
>
>
> Thank you!
> Dinali
>
> --
> *Dinali Rosemin Dabarera*
> Senior Software Engineer
> IAM Domain
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Scope Mapping for OpenID Connect Federated Authenticator

[Asela Pathberiya]

On Mon, Jun 3, 2019 at 6:28 PM Johann Nallathamby  wrote:

>
>
> On Mon, Jun 3, 2019 at 6:25 PM Johann Nallathamby  wrote:
>
>>
>>
>> On Mon, Jun 3, 2019 at 5:29 PM Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Mon, Jun 3, 2019 at 12:22 PM Johann Nallathamby 
>>> wrote:
>>>
>>>> Hi Asela,
>>>>
>>>> As of now I see 2 potential use cases for scope mappings.
>>>>
>>>> 1. There are two different RPs in an organization which are accessed by
>>>> a partner. The application is configured for OpenID Connect delegated
>>>> authentication with WSO2 IS in the organization and WSO2 IS is configured
>>>> for OpenID Connect federation with the partner's in-house OP. The two RPs
>>>> need to consume different set of attributes of the user from the partner
>>>> OP. In this case scope mapping is needed to request attributes from
>>>> federated OP.
>>>>
>>>
>>> Yes this is fine.  I also thought the same.   But this also may be
>>> limited use case as most of the OP may provide the usual attribute with
>>> openid connect scope.
>>>
>>>
>>>>
>>>> 2. An application or api gateway or micro-service in the partner domain
>>>> calls into our API gateway which is protected by OAuth2 in WSO2 IS. WSO2 IS
>>>> is configured for token delegation to accept the partner's scoped access
>>>> tokens and exchange it to our own scoped access tokens. In this case scope
>>>> mapping is needed to issue access tokens with the corresponding restricted
>>>> set of scopes.
>>>>
>>>
>>> To be clear,  I assume that this is to implement which is mentioned in
>>> here [1]  as scope ?
>>>
>>> [1] https://tools.ietf.org/html/rfc7521#section-4.1
>>>
>>
>> Sorry Asela, I actually got the term wrong. I was referring to "token
>> exchange" not "token delegation". But I hope you understood the use case.
>> Now token delegation can be implemented in multiple ways.
>> 1. Custom grant flow to exchange an access token issued by a trusted
>> authorization server to another token from a different authorization server
>> 2. JWT grant flow to exchange a self-contained JWT access token issued by
>> a trusted authorization server to another access token from a different
>> authorization server
>> 3. Token exchange spec -
>> https://tools.ietf.org/id/draft-ietf-oauth-token-exchange-14.html
>>
>
Thanks for clarification!


>
>>
>> In all these implementations if the client has a token from one trusted
>> domain domain and is planning to call a resource server in another domain
>> which is protected by WSO2, then WSO2 must have scope mapping capability in
>> order to translate the original scopes in the access token to scopes in its
>> own domain.
>>
>
> After the scopes are mapped they can be further authorized using XACML or
> something else, but that is the next step.
>
> Regards,
> Johann.
>
>
>> Thanks & Regards,
>> Johann.
>>
>>
>>> Thanks,
>>> Asela.
>>>
>>>
>>>
>>>> Thanks & Regards,
>>>> Johann.
>>>>
>>>> On Fri, May 31, 2019 at 9:43 AM Asela Pathberiya 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby 
>>>>> wrote:
>>>>>
>>>>>> *Problem*
>>>>>>
>>>>>> When we federate to other OpenID Connect Providers, we can send scope
>>>>>> values. However, currently the scope values are fixed per OP we define in
>>>>>> IS. This works fine if the service provider is not a OpenID Connect RP or
>>>>>> an RP not requesting scopes. If we are to support different scope
>>>>>> combinations that can be requested by different RPs, it is not scalable 
>>>>>> to
>>>>>> define individual OP configurations for each scope combination.
>>>>>>
>>>>>> *Solution*
>>>>>>
>>>>>> We must support scope mappings, so that we can map a set of scopes
>>>>>> requested by the RP to another set of scopes supported by the OP. This 
>>>>>> way
>>>>>> we don't need to create multiple OP configurations to support different
>>>>>> scope combinations req

Re: [Architecture] [IAM] Supporting Dynamic Roles using XACML in WSO2 Identity Server

[Asela Pathberiya]

On Mon, May 27, 2019 at 12:28 PM Johann Nallathamby  wrote:

> IAM Team,
>
> Lately I've been thinking of a way to support dynamic roles in WSO2 IS.
> What triggered me was, we already have a tool to author dynamic role
> policies with XACML, albeit its shortcomings. Moreover the limitations in
> the tool is an orthogonal problem to this use case I believe. What is
> missing is an approach to transfer the decision to the service provider as
> part of the authentication response assertion, instead of doing a separate
> authorization call to XACML PDP.
>
> I suggest the following approach:
>
>
+1 for the approach.   This looks like a good usage of using the
capabilities of the XACML


> 1. A user can define a XACML policy with multiple rules, each rule
> corresponding to a dynamic role condition.
> 2. Define an obligation statement for the rule permit criteria and provide
> the dynamic role name as the obligation statement value.
>

Advice element may be suitable than obligation element in XACML as it just
contain some information (dynamic role name)


> 3. The dynamic role names will have a convention. E.g. Dynamic_Role_XXX.
> 4. Extend the default authorization handler in the authentication
> framework, to read the obligations returned from the XACML authorization
> engine, collect all the obligation statements that start with
> "Dynamic_Role_", and add those dynamic role names minus the convention
> prefix, as a multi-valued claim with a special claim URI to the response
> assertion.
>

There is something called AdviceId in the advice element & we can have a
convention for it & retrieve the value from attribute value.   Sample
advice [1]


> 5. Now the service provider who can find the dynamic role names based on
> the special claim URI, understands the meaning of each dynamic role and can
> enforce them on the service provider side.
>
> Thoughts?
>

[1]
http://xacmlinfo.org/2015/01/14/use-xacml-advice-elements-to-generate-detail-decisions/

Thanks,
Asela.


>
> 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]
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Supporting Email or Mobile as the Preferred Communication Channel for the User

[Asela Pathberiya]

On Mon, Jun 3, 2019 at 2:45 PM Johann Nallathamby  wrote:

>
>
> On Mon, Jun 3, 2019 at 1:05 PM Asela Pathberiya  wrote:
>
>>
>>
>> On Thu, May 23, 2019 at 3:48 PM Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Thu, May 23, 2019 at 3:00 PM Johann Nallathamby 
>>> wrote:
>>>
>>>> *Problem*
>>>>
>>>> IS currently supports different types of communication channels in the
>>>> products with the use of output event adaptor such as Email, SMS, HTTP,
>>>> etc. However currently there can be only one channel selected for a given
>>>> deployment based on the configuration.
>>>>
>>>> We have a customer requirement to select either Email or SMS channel
>>>> based on user preference.
>>>>
>>>
>>> +1
>>>
>>> I actually assume that this is already  in the product.  It is
>>> remembered that  we could send the notification type in the API request.
>>> Isn't it ?
>>>
>>
>>
>> Identity mgt API supports something called  notificationType [1].  Based
>> on the type,  notification module would be selected dynamically .  Default
>> module was the email. This was there from the beginning, Can't we use it ?
>>
>
> This is the old identity-mgt implementation isn't it. This implementation
> and the corresponding notification modules are deprecated now. We moved to
> the new identity management implementation and CEP based output event
> adaptor framework from IS 5.3.0 onwards which is more flexible and capable.
>

Yes it is fine.
But  It was great if we could think of  the older API capabilities when it
is being implemented the new API.  Say; if someone was using this feature
in 5.1.0 how does user migrate to newer implementation in new versions ?
IMO;  we need to prioritize & implement this in to the product soon.

Thanks,
Asela.


>
> Regards,
> Johann.
>
>
>>
>> [1]
>> https://github.com/wso2-attic/carbon-identity/blob/v5.0.7/components/identity-mgt/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/services/UserInformationRecoveryService.java#L142
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>> If it is not, we need to have this capabilities.
>>>
>>> Thanks
>>> Asela.
>>>
>>>>
>>>> *Solution*
>>>>
>>>> Previously +Harsha Thirimanna  implemented the
>>>> DefaultNotificationHandler to support different output event streams to be
>>>> chosen based on the scenario of the notification. I think we can extend
>>>> this further to select the output event stream based on scenario as well as
>>>> user's preferred communication address. We can introduce a new reserved
>>>> claim for user's preferred communication address.
>>>>
>>>> Can we confirm this approach unless there is a better way of doing this?
>>>>
>>>> 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]
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> Mobile : +94 777 625 933
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Scope Mapping for OpenID Connect Federated Authenticator

[Asela Pathberiya]

On Mon, Jun 3, 2019 at 12:22 PM Johann Nallathamby  wrote:

> Hi Asela,
>
> As of now I see 2 potential use cases for scope mappings.
>
> 1. There are two different RPs in an organization which are accessed by a
> partner. The application is configured for OpenID Connect delegated
> authentication with WSO2 IS in the organization and WSO2 IS is configured
> for OpenID Connect federation with the partner's in-house OP. The two RPs
> need to consume different set of attributes of the user from the partner
> OP. In this case scope mapping is needed to request attributes from
> federated OP.
>

Yes this is fine.  I also thought the same.   But this also may be limited
use case as most of the OP may provide the usual attribute with openid
connect scope.


>
> 2. An application or api gateway or micro-service in the partner domain
> calls into our API gateway which is protected by OAuth2 in WSO2 IS. WSO2 IS
> is configured for token delegation to accept the partner's scoped access
> tokens and exchange it to our own scoped access tokens. In this case scope
> mapping is needed to issue access tokens with the corresponding restricted
> set of scopes.
>

To be clear,  I assume that this is to implement which is mentioned in here
[1]  as scope ?

[1] https://tools.ietf.org/html/rfc7521#section-4.1

Thanks,
Asela.



> Thanks & Regards,
> Johann.
>
> On Fri, May 31, 2019 at 9:43 AM Asela Pathberiya  wrote:
>
>>
>>
>> On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby 
>> wrote:
>>
>>> *Problem*
>>>
>>> When we federate to other OpenID Connect Providers, we can send scope
>>> values. However, currently the scope values are fixed per OP we define in
>>> IS. This works fine if the service provider is not a OpenID Connect RP or
>>> an RP not requesting scopes. If we are to support different scope
>>> combinations that can be requested by different RPs, it is not scalable to
>>> define individual OP configurations for each scope combination.
>>>
>>> *Solution*
>>>
>>> We must support scope mappings, so that we can map a set of scopes
>>> requested by the RP to another set of scopes supported by the OP. This way
>>> we don't need to create multiple OP configurations to support different
>>> scope combinations requested by different RPs.
>>>
>>> What are your thoughts on this?
>>>
>>
>> I am just wondering why does RP need to send different scopes to
>> federated IDP ?   Is it just to retrieve different attributes from
>> id_token or userinfo attributes based on RP ?   If it is not, is there any
>> other use cases ?
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>> 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]
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Supporting Email or Mobile as the Preferred Communication Channel for the User

[Asela Pathberiya]

On Thu, May 23, 2019 at 3:48 PM Asela Pathberiya  wrote:

>
>
> On Thu, May 23, 2019 at 3:00 PM Johann Nallathamby 
> wrote:
>
>> *Problem*
>>
>> IS currently supports different types of communication channels in the
>> products with the use of output event adaptor such as Email, SMS, HTTP,
>> etc. However currently there can be only one channel selected for a given
>> deployment based on the configuration.
>>
>> We have a customer requirement to select either Email or SMS channel
>> based on user preference.
>>
>
> +1
>
> I actually assume that this is already  in the product.  It is remembered
> that  we could send the notification type in the API request.  Isn't it ?
>


Identity mgt API supports something called  notificationType [1].  Based on
the type,  notification module would be selected dynamically .  Default
module was the email. This was there from the beginning, Can't we use it ?

[1]
https://github.com/wso2-attic/carbon-identity/blob/v5.0.7/components/identity-mgt/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/services/UserInformationRecoveryService.java#L142

Thanks,
Asela.


>
> If it is not, we need to have this capabilities.
>
> Thanks
> Asela.
>
>>
>> *Solution*
>>
>> Previously +Harsha Thirimanna  implemented the
>> DefaultNotificationHandler to support different output event streams to be
>> chosen based on the scenario of the notification. I think we can extend
>> this further to select the output event stream based on scenario as well as
>> user's preferred communication address. We can introduce a new reserved
>> claim for user's preferred communication address.
>>
>> Can we confirm this approach unless there is a better way of doing this?
>>
>> 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]
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> Mobile : +94 777 625 933
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Scope Mapping for OpenID Connect Federated Authenticator

[Asela Pathberiya]

On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby  wrote:

> *Problem*
>
> When we federate to other OpenID Connect Providers, we can send scope
> values. However, currently the scope values are fixed per OP we define in
> IS. This works fine if the service provider is not a OpenID Connect RP or
> an RP not requesting scopes. If we are to support different scope
> combinations that can be requested by different RPs, it is not scalable to
> define individual OP configurations for each scope combination.
>
> *Solution*
>
> We must support scope mappings, so that we can map a set of scopes
> requested by the RP to another set of scopes supported by the OP. This way
> we don't need to create multiple OP configurations to support different
> scope combinations requested by different RPs.
>
> What are your thoughts on this?
>

I am just wondering why does RP need to send different scopes to federated
IDP ?   Is it just to retrieve different attributes from  id_token or
userinfo attributes based on RP ?   If it is not, is there any other use
cases ?

Thanks,
Asela.


>
> 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]
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] Supporting Email or Mobile as the Preferred Communication Channel for the User

[Asela Pathberiya]

On Thu, May 23, 2019 at 3:00 PM Johann Nallathamby  wrote:

> *Problem*
>
> IS currently supports different types of communication channels in the
> products with the use of output event adaptor such as Email, SMS, HTTP,
> etc. However currently there can be only one channel selected for a given
> deployment based on the configuration.
>
> We have a customer requirement to select either Email or SMS channel based
> on user preference.
>

+1

I actually assume that this is already  in the product.  It is remembered
that  we could send the notification type in the API request.  Isn't it ?

If it is not, we need to have this capabilities.

Thanks
Asela.

>
> *Solution*
>
> Previously +Harsha Thirimanna  implemented the
> DefaultNotificationHandler to support different output event streams to be
> chosen based on the scenario of the notification. I think we can extend
> this further to select the output event stream based on scenario as well as
> user's preferred communication address. We can introduce a new reserved
> claim for user's preferred communication address.
>
> Can we confirm this approach unless there is a better way of doing this?
>
> 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]
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IAM] What is our Strategy on Local Account Linking?

[Asela Pathberiya]

On Fri, Apr 19, 2019 at 5:21 AM Ruwan Abeykoon  wrote:

> Hi Johann,
> +1 for implementing the use-case.
> We need to have a white-board session to capture all the possible cases,
> and modules to be touched.
>
> Can we do this once the release pressure is over? For the prospect, can we
> say this is in our roadmap.
>
> Cheers,
> Ruwan A
>
>
> On Thu, Apr 18, 2019 at 4:45 PM Johann Nallathamby 
> wrote:
>
>> IAM Team,
>>
>> I know we just have a facility to store and manage linked local accounts.
>> However we don't use it anywhere. There have been many customers and/or
>> leads in the past who have requested for this capability for different
>> kinds of requirements and mostly we've provided extensions but never
>> thought about making it part of the product. Do we have any plans on
>> improving this aspect?
>>
>> Currently I am working with one customer and one prospect who have the
>> following 2 requirements respectively:
>>
>> 1. A user must authenticate with username/password in secondary user
>> store and fetch attributes from primary user store and return back to the
>> service provider.
>>
>> 2. A user can have multiple accounts in the local user store. Same user
>> also has a federated identity. The user should be able to link the
>> federated identity to both the local identifiers. When logging in the user
>> will choose, federated login and then on IS choose which local identity to
>> login as.
>>
>
+1

It looks like aggregating user attributes from multiple local user stores.
I remember that simple implementation was done for it long time back [1]

[1]
http://soasecurity.org/2015/03/03/configure-attribute-sources-with-wso2-identity-server/


Thanks,
Asela.

>
>> What is our strategy on local account linking? If needed we can have an
>> offline discussion on this.
>>
>> 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]
>>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Thanks & Regards,
Asela

Mobile : +94 777 625 933

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

Re: [Architecture] [IS] On Board Diagnostics Tool for IS

[Asela Pathberiya]

On Thu, Sep 6, 2018 at 4:15 PM, Sinthuja Rajendran 
wrote:

> Hi,
>
> I have a few questions/concerns on as stated below.
>
> 1)  In our WSO2 servers startup script, we do have below java props [1],
> which basically can create a heap dump when the server has gone OOM.
> Therefore, I believe here you are trying to solve the problem that the
> server continues to run, although there is an OOM. IMHO logs are not a
> suitable mechanism to find whether the system has gone OOM, because we
> can't certainly produce all kind of logs for OOM error. And also in the
> proposed method, we can only solve the problem after it has occurred (ie,
> incur system outage), and we can't prevent it. IMHO, running the system/JVM
> monitoring tool which can monitor and alert after exceeding some percentage
> of memory usage is the better solution to solve this problem.
>

> 2) Thread dumps are mostly related to slow response (sometimes no
> response) from the server, and I'm not sure how can we get these details
> from the logs. And we need to intelligently handle the logs, just because
> of some request timeout that doesn't mean that we need to take the thread
> dump, and it can be simply some backend service is down.
>
> 3) We have carbon-dump.sh which can dump all the thread-dump, heap-dump,
> relevant details about the server. Can't we use that for this purpose?
>

Yes!  Looking at the logs to take heap/thread dumps, would not help much.

Is there any other dump or data which you are hoping to zip ?

Also;  How does this specific to IS ?  Is there any special diagnosis which
you are hoping for IS ? If it is, what are them ?

Thanks,
Asela.


>
> [1] -XX:+HeapDumpOnOutOfMemoryError \
> -XX:HeapDumpPath="$RUNTIME_HOME/logs/heap-dump.hprof" \
>
> Thanks,
> Sinthuja.
>
> On Thu, Sep 6, 2018 at 3:25 PM Thumilan Mikunthan 
> wrote:
>
>> Hi all,
>>
>> *Problem*
>>
>> Whenever an error occurred (depending on that error) certain diagnostics
>> actions can help to diagnose the error.
>>
>> For example,
>>
>>-
>>
>>If OOM (Out Of Memory) error occured heap dump will help to analyse
>>memory leak.
>>-
>>
>>If some threads blocked abnormally, analyzing thread dump could be
>>able to solve the problem.
>>
>> But in real scenario, doing these diagnostic actions manually may not
>> possible because
>>
>>-
>>
>>Unable to predict when will the error come.
>>-
>>
>>Depending on error diagnostics actions may vary, expecting that user
>>acknowledged about all error scenarios is impossible.
>>-
>>
>>User willing to take support from support team instead of solving the
>>error himself/herself.
>>
>>
>> *Solution*
>>
>> Design a stand alone tool which has less memory footprint (<8%) and less
>> CPU usage (<8%) which has following workflow.
>>
>>-
>>
>>Log Tailer tails the carbon.log file in real time.
>>-
>>
>>Match Rule Engine checks whether current log line and error regex are
>>matching or not.
>>-
>>
>>   Tool has to read error regexs from separate xml file.
>>   -
>>
>>Interpreter identify the error type and do actions regarding that
>>error.
>>-
>>
>>   Each action should handle by separate action executer.
>>   -
>>
>>   Mapping between errors and actions should be written in separate
>>   xml file.
>>   -
>>
>>All the diagnostics files (eg:- thread dumps and heap dumps) for a
>>particular error should be created under one folder and zip the folder.
>>-
>>
>>   Each folder can identify by time instance
>>
>>
>> *Architecture Diagram*
>> [image: ArchitectureDiagram.png]
>>
>> *Sample Scenario*
>>
>> Assume that client reporting issue about OOM error. He usually attaches
>> carbon.log file along with the issue. But in order to solve the problem
>> support team needs thread dump and heap dump. So team requires client to
>> take those dumps next time. Client has to wait next time and take those
>> dumps. (We can’t expect client to watch the server all the time and get
>> dumps when error occurs. What if next error occurs at midnight?). Support
>> team has to wait for the update on that issue. So they put the issue on
>> pause and goes on.
>>
>> Now consider above problem scenario with this tool. Once the error
>> occurred the tool will take necessary diagnostic actions and zip the
>> folder. Client can upload that zip folder with the issue so that the
>> support team doesn’t need client to do those diagnostic actions himself.
>> The support team able to work on that issue directly without expecting any
>> updates from the client.
>>
>> The next time error occurs (even at midnight) tool can detect the error
>> and send necessary files to support time directly for further analysis.
>>
>> Hence the tool’s memory footprint is small, client can run the tool
>> without any objection.
>>
>> The tool reduces client’s involvement on WSO2 IS errors so that client
>> can focus on their business. Tool also helps to redu

Re: [Architecture] Can we ship Identity Management / Identity Governance features with APIM by default.

[Asela Pathberiya]

Guys,  I do not think you have understood what i am pointing here.

Lets me explain it clearly

Say; i have a distributed setup which contains APIM GW + APIM
(store/publisher) + KM (Here KM can be any OAuth2 authorization server).

To achieve, user locking function for store users,  You are asking me to
use WSO2 Identity server ? Therefore I need to externalize the
authentication + use WSO2IS for only that function.  What is waste of it ?
It would cost me a lot. :) I do not want to spend more money on this APIM
project  :D

Also, if i am running with all in one deployment, it is also the same!


On Mon, Feb 5, 2018 at 8:08 PM, Sagara Gunathunga  wrote:

>
>
> On Mon, Feb 5, 2018 at 12:56 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Mon, Feb 5, 2018 at 12:36 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Mon, Feb 5, 2018 at 12:10 PM, Nuwan Dias  wrote:
>>>
>>>> As mentioned on the subject itself, these are Identity Management and
>>>> Identity Governance features. They don't closely tie in with API
>>>> Management. Therefore I think its fine to recommend IS for those kind of
>>>> use cases.
>>>>
>>>> Installing these features to APIM at this point in time is also a
>>>> problem due to its roadmap with 3.0. If we install these features into APIM
>>>> users will see these as first class features of our APIM offering, they
>>>> won't see this as something coming from IS.
>>>>
>>>
>>> APIM store is public facing for end users.  It already supports for user
>>> registration which is also identity management feature.  It is a question,
>>> why can't it support  features such as  password recovery/policies/email
>>> activation by default.
>>>
>>
>> Its not that it can't. Its a question of where do we draw the line
>> between IS and APIM. My opinion is that the current user registration (with
>> workflow support) and password reset options are just enough for the OOTB
>> product.
>>
>
It is not enough when public user registrations are supported.  You need to
have proper password management & account locking to support advance
security features.  You would be surely caught with DoS attacks/Security
scanning would be failed


> You can have many more scenarios than listed above. Such as Login with
>> Facebook, Multifactor Authentication, etc and the list could go on. I think
>> its fine to ask users to integrate with IS for advanced scenarios.
>>
>
Yes! If it is needed the federation,  it is fine to use the WSO2IS as auth
manager as it is advance use case as users are not governed by the APIM
user store.


>
> We have very clear boundaries between API-M and IS, this is the whole
> point for maintaining IS as the key manager profile so that users can get
> both IS and KM capabilities from a single runtime, I don't see any valid
> point to make API-M runtime more complicate by adding some random IS
> features (in this case Identity Governance features) hence I'm also -1 for
> original suggestion.
>

There are not just random feature! You need these when you have a public
user registration.


Thanks,
Asela.


> IMO two runtime concept we have today ( API-M KM and IS as KM ) is enough
> to cater simple API security requirements to complex IAM requirements.
>

> Thanks !
>
>>
>>> If product supports for public user registration, it must support for
>>> all other identity management features as well.
>>>
>>> Are we removing the user registration from APIM 3.0 ?
>>>
>>
>> No, that would be there. But we don't have plans to support anything
>> else. Since there's no C5 based IS yet, we are writing all the user
>> management capabilities from scratch to even get the basic functionality.
>> The need to support more and more scenarios would create a lot more work
>> than already planned. Risking its deadlines.
>>
>>>
>>> Thanks,
>>> Asela.
>>>
>>>
>>>> Which means that users would expect the same set of features on 3.0 as
>>>> well. Therefore I would be -1 to installing these features on APIM.
>>>>
>>>> On Mon, Feb 5, 2018 at 9:49 AM, Asela Pathberiya 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> There are several customers/users who are looking for $subject with
>>>>> APIM.  Specially following features
>>>>>
>>>>> 1. Account lock/disable
>>>>> 2. Password/Account recovery
>>>>> 3. Password policies
>>>>>
>

Re: [Architecture] Can we ship Identity Management / Identity Governance features with APIM by default.

[Asela Pathberiya]

On Mon, Feb 5, 2018 at 12:10 PM, Nuwan Dias  wrote:

> As mentioned on the subject itself, these are Identity Management and
> Identity Governance features. They don't closely tie in with API
> Management. Therefore I think its fine to recommend IS for those kind of
> use cases.
>
> Installing these features to APIM at this point in time is also a problem
> due to its roadmap with 3.0. If we install these features into APIM users
> will see these as first class features of our APIM offering, they won't see
> this as something coming from IS.
>

APIM store is public facing for end users.  It already supports for user
registration which is also identity management feature.  It is a question,
why can't it support  features such as  password recovery/policies/email
activation by default.

If product supports for public user registration, it must support for all
other identity management features as well.

Are we removing the user registration from APIM 3.0 ?

Thanks,
Asela.


> Which means that users would expect the same set of features on 3.0 as
> well. Therefore I would be -1 to installing these features on APIM.
>
> On Mon, Feb 5, 2018 at 9:49 AM, Asela Pathberiya  wrote:
>
>> Hi All,
>>
>> There are several customers/users who are looking for $subject with
>> APIM.  Specially following features
>>
>> 1. Account lock/disable
>> 2. Password/Account recovery
>> 3. Password policies
>>
>> We are usually not recommending the feature installation.  Therefore,
>> shall we ship these features by default with APIM.
>>
>> However, we can suggests to use WSO2IS as KM,  but we need to consider on
>>
>> 1.  Cost on running WSO2IS (infra cost)
>> 2.  All in one deployment
>> 3.  First impression on the IAM feature list of APIM.
>>
>> WDYT ?
>>
>> Thanks,
>> Asela.
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933 <+94%2077%20762%205933>
 +358 449 228 979

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

[Architecture] Can we ship Identity Management / Identity Governance features with APIM by default.

[Asela Pathberiya]

Hi All,

There are several customers/users who are looking for $subject with APIM.
Specially following features

1. Account lock/disable
2. Password/Account recovery
3. Password policies

We are usually not recommending the feature installation.  Therefore,
shall we ship these features by default with APIM.

However, we can suggests to use WSO2IS as KM,  but we need to consider on

1.  Cost on running WSO2IS (infra cost)
2.  All in one deployment
3.  First impression on the IAM feature list of APIM.

WDYT ?

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] supported databases for WSO2 IS

[Asela Pathberiya]

On Wed, Jan 17, 2018 at 12:11 AM, Roman CHRENKO 
wrote:

> Thank you.
>
> Do you have any test cases for database testing?
>
> Maybe I could test some of them (although I don't know if we will go to
> IS 5.4.0).
>

There is no specific test case for database testing.   But if you test your
use cases, they would cover them as well.


> Best regards,
>
> Roman Chrenko
>
>
>
> *From:* Architecture [mailto:architecture-boun...@wso2.org] *On Behalf Of
> *Asela Pathberiya
> *Sent:* Tuesday, January 16, 2018 4:01 PM
> *To:* architecture 
> *Subject:* Re: [Architecture] supported databases for WSO2 IS
>
>
>
>
>
>
>
> On Tue, Jan 16, 2018 at 8:06 PM, Roman CHRENKO 
> wrote:
>
> Hi.
>
> I would like to know what databases are supported with WSO2 IS 5.4 (5.3).
>
> By https://docs.wso2.com/display/IS540/Installation+Prerequisites =>
> Working with Databases (https://docs.wso2.com/
> display/ADMIN44x/Working+with+Databases):
>
> "For most production environments, we recommend industry-standard RDBMSs
> such as Oracle, PostgreSQL, MySQL, MS SQL, etc."
>
> By https://docs.wso2.com/display/compatibility/Tested+DBMSs:
>
> IS 5.4.0 is tested with "MySQL 5.7" and "MsSql 2014" and IS 5.3.0 is
> tested also with  "SQL Server  2012", "Oracle 12.1.0.2" and "PostgreSQL
> 9.3.6".
>
>
>
> We are in the phase of planning infrastructure for production environment,
> so it is very important for us to know if "Oracle 12.1.0.2" (and possibly
> "PostgreSQL 9.3.6" or "MariaDB") is supported with WSO2 5.4.
>
> Is Identity Server 5.4.0 compatible with all the databases from version
> 5.3.0? 5.2.0? ...
>
>
>
> Theoretically WSO2IS must support for any RDBMS with any versions but it
> is tested (QAed) with specific versions before releasing as it is not
> practically test it with all the combinations. However, if there are any
> issues with given version, it must be fixed (Mostly the database script)
>
>
>
> Therefore it is great, if you can test & verify whether all the use-cases
> are working fine with the versions that you preferred.
>
>
>
> Thanks,
>
> Asela.
>
>
>
>
>
> Best regards,
>
> Roman Chrenko
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
>
>
>
> --
>
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Password Rotation Policy Authenticator

[Asela Pathberiya]

On Tue, Jan 16, 2018 at 9:11 PM, Johann Nallathamby  wrote:

>
>
> On Tue, Jan 16, 2018 at 8:27 PM, Ruwan Abeykoon  wrote:
>
>> Hi Asela,
>> While agreeing the concerns of separate pack, we have different concerns
>> too to address,
>>
>> 1. We are moving towards micro-services world and container nativeness.
>> Adding more functionalities into single JVM is not the best move. The idea
>> is on service do single task to the best.
>> 2. Due to load on the server on querying the database on scheduler. We
>> have seen this problem in notorious session cleanup task. Iterating over
>> all the records in a live DB while modifying the same set of records is
>> considered a dangerous thing. This can not be done in theory.
>>
>> Yes, some users opt doing this with iterating over user store. This is
>> fragile and bound to be failed an any point of time.
>>
>> So, lets do the correct thing, let the analytics do things it is strong
>> and lets keep things simple.
>>
>> Also since we emit the events, customer is not tied to DAS or IS
>> analytics. They can insert those in their own structure (May be RDBMS,
>> REDIS, elastic search) and do any queries they wish, such as writing custom
>> scripts. So we are allowing more possibilities with this approach (not
>> providing hard set of functionalities inside IS).
>>
>
> +1 for this architecture.
>
> *@Asela*: the incremental cost seems to be big only because we only have
> a few of things right now we get from IS Analytics. The Analytics
> dashboards, Suspicious activity alerts, Session termination and now this
> new feature. But there are some more features IAM team is planning to do
> using IS Analytics in the space of  fraud detection and threat
> intelligence. Once we have tapped the full potential of IS Analytics users
> will see the value I think. Spinning up an additional server won't be seen
> as costly then.
>

Agreed on above!

My concern is that; when we are introducing a new feature/improvement,  It
is better to have an easy way which will help users/customers to try out
without any cost.  Yes! extensible/distributed deployment must be there.


>
> Regards,
> Johann.
>
>
>>
>> Cheers,
>> Ruwan
>>
>> On Tue, Jan 16, 2018 at 2:32 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Jan 16, 2018 at 2:01 PM, Nadun De Silva  wrote:
>>>
>>>> Hi Asela,
>>>>
>>>> On Tue, Jan 16, 2018 at 12:14 PM, Asela Pathberiya 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 16, 2018 at 11:16 AM, Nadun De Silva 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> At the moment the authenticator only has the *"password expiration
>>>>>> time period"* in the password expiration policy.
>>>>>>
>>>>>> So I can start off by altering the authenticator to publish the
>>>>>> following to analytics
>>>>>>
>>>>>
>>>>> Do we need to deploy an analytic instance to use this
>>>>> authenticator...  Is it something mandatory ?
>>>>>
>>>>> If we use the current approach mentioned before, the analytics
>>>> instance is *not required to use the* *authenticator*. However, the
>>>> analytics instance would be *required to use the password expiration
>>>> notifications*. If the user does not use the analytics instance only
>>>> the notifications will be disabled.
>>>>
>>>>
>>>>> Can we simply store & implement task inside WSO2IS to achieve this ?
>>>>>
>>>>
>>>> We did consider spawning a task to achieve this. But there were several
>>>> issues pointed out in our discussions.
>>>>
>>>>- If the task is inside the identity Server instance, it will have
>>>>a periodic workload of going through all the users and finding the users
>>>>whose passwords had expired.
>>>>   - This is especially a concern when the number of users is
>>>>   really high.
>>>>   - Siddhi or a Spark query will be able to handle this more
>>>>   efficiently.
>>>>- By using the analytics instance and only emitting the password
>>>>changed events from the identity server we can decouple the 
>>>> notifications.
>>>>   - This gives the admin more freedom over the notifications.
>>>

Re: [Architecture] supported databases for WSO2 IS

[Asela Pathberiya]

On Tue, Jan 16, 2018 at 8:06 PM, Roman CHRENKO 
wrote:

> Hi.
>
> I would like to know what databases are supported with WSO2 IS 5.4 (5.3).
>
> By https://docs.wso2.com/display/IS540/Installation+Prerequisites =>
> Working with Databases (https://docs.wso2.com/
> display/ADMIN44x/Working+with+Databases):
>
> "For most production environments, we recommend industry-standard RDBMSs
> such as Oracle, PostgreSQL, MySQL, MS SQL, etc."
>
> By https://docs.wso2.com/display/compatibility/Tested+DBMSs:
>
> IS 5.4.0 is tested with "MySQL 5.7" and "MsSql 2014" and IS 5.3.0 is
> tested also with  "SQL Server  2012", "Oracle 12.1.0.2" and "PostgreSQL
> 9.3.6".
>
>
>
> We are in the phase of planning infrastructure for production environment,
> so it is very important for us to know if "Oracle 12.1.0.2" (and possibly
> "PostgreSQL 9.3.6" or "MariaDB") is supported with WSO2 5.4.
>
> Is Identity Server 5.4.0 compatible with all the databases from version
> 5.3.0? 5.2.0? ...
>

Theoretically WSO2IS must support for any RDBMS with any versions but it is
tested (QAed) with specific versions before releasing as it is not
practically test it with all the combinations. However, if there are any
issues with given version, it must be fixed (Mostly the database script)

Therefore it is great, if you can test & verify whether all the use-cases
are working fine with the versions that you preferred.

Thanks,
Asela.


>
>
> Best regards,
>
> Roman Chrenko
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] GDPR - Pseudonyms For Username

[Asela Pathberiya]

On Fri, Jan 5, 2018 at 5:50 PM, Jayanga Kaushalya  wrote:

> Hi all,
>
> According to the GDPR act [1] Chapter 3, Section 3, Article 17 (Right to
> erasure) the data subject has the authority to request the erasure of the
> data from controller. And the controller has the authority to erase the
> data according to the conditions given in the Article 17. And in an event
> of erasure request, it should perform the action without giving an extreme
> delay and erase all of the relevant information.
>
> In the current implementation, some of the user information (Ex: username)
> scattered around multiple locations and it is technically hard to clear all
> of the data from a single action without giving a significant delay. For an
> example there are instances username is printed in logs and it is
> technically difficult to erase those instances from logs.
>
> *Solution - Introducing Pseudonyms for Username*
>
> By introducing a pseudonym for username we can limit the usage of actual
> username throughout the system. By doing this erasure of actual username
> will remove the underlying value represented by the pseudonym attached to
> it. Hence it'll make the removal of user information from all of the
> related locations technically feasible. There are two main approaches to
> implement the pseudonyms for username which are below described.
>
> *Approach 1 *
>
> Keep the core implementation to work with usernames and change all of the
> output locations to convert username to relevant pseudonym and output.
>
> *Approach 2*
>
> Change the core implementation to work with pseudonym and change the
> places where the user friendly username is required.
>
> *Preferred Approach*
>
> Approach number 2 is selected as the best approach since all of the
> internal usages will be change to use the pseudonym and in a event of
> failure pseudonym will be displayed instead of the actual username which
> will guaranty the compliance.
>


It seems to be that approach 2 would add some more advantages such as
implementing the usename renaming.  But we need to more careful with the
design as interfaces may be needed to modify.

Are we storing the pseudonyms vs username in somewhere ?  internal store or
user store ?

When it comes to username. Does it consider as   user store domain + user
store username  + tenant domain or just user store username  ?


>
> [1] http://data.consilium.europa.eu/doc/document/ST-5419-2016-INIT/en/pdf
>
> Thanks!
>
> *Jayanga Kaushalya*
> Senior Software Engineer
> Mobile: +94777860160 <+94%2077%20786%200160>
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Password Rotation Policy Authenticator

[Asela Pathberiya]

On Tue, Jan 16, 2018 at 2:01 PM, Nadun De Silva  wrote:

> Hi Asela,
>
> On Tue, Jan 16, 2018 at 12:14 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Jan 16, 2018 at 11:16 AM, Nadun De Silva  wrote:
>>
>>> Hi,
>>>
>>> At the moment the authenticator only has the *"password expiration time
>>> period"* in the password expiration policy.
>>>
>>> So I can start off by altering the authenticator to publish the
>>> following to analytics
>>>
>>
>> Do we need to deploy an analytic instance to use this authenticator...
>> Is it something mandatory ?
>>
>> If we use the current approach mentioned before, the analytics instance
> is *not required to use the* *authenticator*. However, the analytics
> instance would be *required to use the password expiration notifications*.
> If the user does not use the analytics instance only the notifications will
> be disabled.
>
>
>> Can we simply store & implement task inside WSO2IS to achieve this ?
>>
>
> We did consider spawning a task to achieve this. But there were several
> issues pointed out in our discussions.
>
>- If the task is inside the identity Server instance, it will have a
>periodic workload of going through all the users and finding the users
>whose passwords had expired.
>   - This is especially a concern when the number of users is really
>   high.
>   - Siddhi or a Spark query will be able to handle this more
>   efficiently.
>- By using the analytics instance and only emitting the password
>changed events from the identity server we can decouple the notifications.
>   - This gives the admin more freedom over the notifications.
>   - We can do further analytics to identify anomalies and threats.
>
>
Got it.  But in a user/customer point of view, I just need to configure an
authenticator to achieve password expiry notification with WSO2IS.   For
that; I need to download separate pack & install it in separate java
instance & maintain it separately.  It is cost.  Why i am spending this
much of cost to enable this feature ?  IMO;  we need to think of that
aspect as well.

I have seen some users have already implemented a small script which calls
the LDAP user store & verifies the password updated date & sends mails.

Thanks,
Asela.


>>  Thanks,
>> Asela.
>>
>>
>>>- The password expiration time period config change
>>>- The password changed event
>>>
>>> Also, the high-level architecture would be as follows.
>>>
>>>
>>> ​
>>>
>>> Any comments or improvements are highly appreciated.
>>>
>>> Thank you!
>>>
>>> Regards,
>>> NadunD
>>>
>>> On Tue, Jan 16, 2018 at 6:39 AM, Ruwan Abeykoon  wrote:
>>>
>>>> Hi Dimuthu,
>>>> I would suggest storing the expiration policy in IS side. How and where
>>>> this can be stored yet to be discussed. For the time being, we can play
>>>> around registry for quick start( but registry will go away soon)
>>>> IS needs to emit an event towards analytics upon any change in the
>>>> policy. This change will then be stored in analytics side too, and used as
>>>> parameters on Siddhi (preferable) or Spark queries.
>>>>
>>>> This will decouple the policy from the code. Hence "Identity Admin" is
>>>> given chance implement most of things that can bed imagine.
>>>>
>>>> We provide default policy + default query. But "Identity Admin" can
>>>> modify them without code change and change will be immediately live.
>>>>
>>>> Cheers,
>>>> Ruwan
>>>>
>>>>
>>>> On Tue, Jan 16, 2018 at 3:03 AM, Dimuthu Leelarathne >>> > wrote:
>>>>
>>>>> Hi Nadun,
>>>>>
>>>>>
>>>>> On Mon, Jan 15, 2018 at 9:01 PM, Nadun De Silva 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have started working on a Password Rotation Policy Authenticator
>>>>>> for the Identity Server.
>>>>>>
>>>>>> Currently, there is an authenticator [1] which can be used to force
>>>>>> the user to change the password.
>>>>>>
>>>>>> However, it does not support the following requirements on its own.
>>>>>>
>>>>>>- Force the user to change the password to a *pre

Re: [Architecture] [RRT] XACML based scope validator (during OAuth2 token validation)

[Asela Pathberiya]

On Tue, Jan 16, 2018 at 12:05 PM, Senthalan Kanagalingam  wrote:

> Hi Johann,
>
> Thanks for the feedback. Currently, I am checking that feature.
>

You can find the sample implementation for XACML based scope validator from
here [1] .  It would help.

[1]
http://xacmlinfo.org/2014/10/24/authorization-for-apis-with-xacml-and-oauth-2-0/

Thanks,
Asela.



>
> According to my understanding, this feature will be useful to validate the
> token scopes against resource scopes. As this validation is done by
> JDBCScopeValidator and my implementation will be parallel to it (IS allows
> multiple scope validators), do I have to implement validation of the token
> scopes against the resource scopes as well?
>
> Because I have checked with identity-application-authz-xacml[1
> ]
> and planned to implement validating scopes against the role base and time
> base policies only.
>
> [1] - https://github.com/wso2-extensions/identity-application-authz-xacml
>
> Regards,
> Senthalan
>
> On Mon, Jan 15, 2018 at 8:13 PM, Johann Nallathamby 
> wrote:
>
>> *[-IAM, RRT]*
>>
>> On Mon, Jan 15, 2018 at 8:13 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Senthalan,
>>>
>>> Did you check [1]? In this feature *@Isuranga* implement XACML policy
>>> to evaluate the permission tree. For this he had to come up with a policy,
>>> that defined a custom function.
>>>
>>> In the above feature if you replace permission with OAuth2 scopes (which
>>> is also a representation of permissions in OAuth2 world, and can be
>>> assigned to roles from IS 5.4.0 onwards IINM) you will get what you need.
>>> Am I right? Do you see any gaps?
>>>
>>> If my wit is good, this will be the best way to implement this feature.
>>>
>>> [1] [IAM] Restful API to Evaluate Permission Tree in IS
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Fri, Jan 12, 2018 at 2:10 PM, Senthalan Kanagalingam <
>>> sentha...@wso2.com> wrote:
>>>
 Hi all,

 As the aim of this project is to validate the scope of the token
 against XACML policies. I was wrong about the extension point. There is no
 need to implement it from token validation point. There is an extension
 point to extends scope validation("OAuth2ScopeValidator"). And  IS
 allows multi-scope validators. So  I am going start from here.

 Thanks and Regards,
 Senthalan

 On Thu, Jan 11, 2018 at 5:35 PM, Senthalan Kanagalingam <
 sentha...@wso2.com> wrote:

> Hi all,
>
> I am currently working on implementing XACML based scope validator
> when the resource server tries to validate the OAuth2 token. Users
> can publish their token validation XACML policies to the policy store. 
> Here[
> 1
> ]
> is a sample policy template.
>
> The spec implementation of the OAuth2 token validation is already in
> WSO2 IS. If spec validation passed only this validator will be called.
> XACML request will be created using the retrieved information of the
> user. Then that XACML request will be validated using the entitlement
> engine.
>
> There will be a global configuration to enable or disable this
> validation. But in future, it will be implemented as a configurable
> option for each service provider.
>
> WSO2 IS have an extension point to implement TokenValidator[2
> ].
> I am planning to implement custom validator 
> ("XACMLbasedOAuth2TokenValidator")
> at the point for validation.
>
> I am looking forward to suggestions/comments.
>
> [1] -  https://docs.google.com/document/d/1unh9QsDXMXxwbr3SPYLgRG1m
> KvxphX9VjhRAthHIlQU/edit?usp=sharing
> [2] - https://docs.wso2.com/display/IS540/Extension+Points+for+OAu
> th#ExtensionPointsforOAuth-OAuth2TokenValidator
>
> Thanks and Regards,
> Senthalan
> --
>
> *Senthalan Kanagalingam*
> *Software Engineer - WSO2 Inc.*
> *Mobile : +94 (0) 77 18 77 466*
> 
>



 --

 *Senthalan Kanagalingam*
 *Software Engineer - WSO2 Inc.*
 *Mobile : +94 (0) 77 18 77 466*
 

>>>
>>>
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile: *+94 77 7776950*
>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>> *
>>> Medium: *https://medium.com/@johann_nallathamby
>>> *
>>> Twitter: *@dj_nallaa*
>>>
>>
>>
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: *+94 77 7776950*
>> Linked

Re: [Architecture] Password Rotation Policy Authenticator

[Asela Pathberiya]

On Tue, Jan 16, 2018 at 11:16 AM, Nadun De Silva  wrote:

> Hi,
>
> At the moment the authenticator only has the *"password expiration time
> period"* in the password expiration policy.
>
> So I can start off by altering the authenticator to publish the following
> to analytics
>

Do we need to deploy an analytic instance to use this authenticator...  Is
it something mandatory ?

Can we simply store & implement task inside WSO2IS to achieve this ?

 Thanks,
Asela.


>- The password expiration time period config change
>- The password changed event
>
> Also, the high-level architecture would be as follows.
>
>
> ​
>
> Any comments or improvements are highly appreciated.
>
> Thank you!
>
> Regards,
> NadunD
>
> On Tue, Jan 16, 2018 at 6:39 AM, Ruwan Abeykoon  wrote:
>
>> Hi Dimuthu,
>> I would suggest storing the expiration policy in IS side. How and where
>> this can be stored yet to be discussed. For the time being, we can play
>> around registry for quick start( but registry will go away soon)
>> IS needs to emit an event towards analytics upon any change in the
>> policy. This change will then be stored in analytics side too, and used as
>> parameters on Siddhi (preferable) or Spark queries.
>>
>> This will decouple the policy from the code. Hence "Identity Admin" is
>> given chance implement most of things that can bed imagine.
>>
>> We provide default policy + default query. But "Identity Admin" can
>> modify them without code change and change will be immediately live.
>>
>> Cheers,
>> Ruwan
>>
>>
>> On Tue, Jan 16, 2018 at 3:03 AM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi Nadun,
>>>
>>>
>>> On Mon, Jan 15, 2018 at 9:01 PM, Nadun De Silva  wrote:
>>>
 Hi all,

 I have started working on a Password Rotation Policy Authenticator for
 the Identity Server.

 Currently, there is an authenticator [1] which can be used to force the
 user to change the password.

 However, it does not support the following requirements on its own.

- Force the user to change the password to a *previously unused
password*
- *Notify the user* when the password had expired

 According to my research, I found out that the *user can be forced to
 change the password to a previously unused password using the Password
 History Validation Policy* [2] and the authenticator [1]. However, the
 authenticator does not show a proper message to the user. I am planning to
 fix this.

 I have also started working on the *password expiry notifications*.
 The planned approach that will be used is as follows,

- Emit the password change event to analytics
- Use an analytic query to identify the user's whose passwords had
expired


>>> Where do we hope to maintain the password expiration policy? It is at
>>> the identity server side. Can analytics query can invoke a REST API on
>>> identity server side to retrieve it?
>>>
>>> thanks,
>>> Dimuthu
>>>
>>>
>>> This approach was selected as this will have a minimal load on the
 identity server instance as well as it will also open up the path to do
 further analytics to identify anomalous user behaviors.

 Any suggestions or improvements are highly appreciated.

 [1] https://store.wso2.com/store/assets/isconnector/details/
 502efeb1-cc59-4b62-a197-8c612797933c
 [2] https://docs.wso2.com/display/IS530/Password+History+Validation

 Thank you!

 Regards,
 NadunD

 --
 *Nadun De Silva*
 Software Engineer | WSO2

 Email: nad...@wso2.com
 Mobile: +94778222607 <077%20822%202607>
 Web: http://wso2.com

 

>>>
>>>
>>>
>>> --
>>> Dimuthu Leelarathne
>>> Director, Solutions Architecture
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: dimut...@wso2.com
>>> Mobile: +94773661935 <+94%2077%20366%201935>
>>> Blog: http://muthulee.blogspot.com
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com  *
>> *lean.enterprise.middleware.*
>>
>>
>
>
> --
> *Nadun De Silva*
> Software Engineer | WSO2
>
> Email: nad...@wso2.com
> Mobile: +94778222607 <+94%2077%20822%202607>
> Web: http://wso2.com
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Federated IdP Initiated Logout

[Asela Pathberiya]

On Mon, Jan 15, 2018 at 2:39 PM, Rasika Perera  wrote:

> Hi Dimuthu,
>
> Recently, we did a similar setup, which involves a Federated IDP of OIDC.
> All internal apps configured with SAML SSO. Login flow worked smoothly with
> oidc authenticator; however external apps initiated logout(inbound logout
> requests from OIDC-to-SAML) and internal apps initiated logout(outbound
> logout requests SAML-to-OIDC) were not supported.
>


This is not similar which Dimuthu has mentioned.  It uses  SAML2 SSO to
communicate between WSO2IS & federated IDP. Are we going to support both
protocols (OIDC & SAML2 SSO logout ) ?

Thanks,
Asela.


>
> [image: Inline image 1]
>
> @Darshana
> I believe we can re-use this session management capability for our use
> case as well. Then we can reduce the effort duplication. WDYT?
>
> Best Regards,
> ~Rasika
>
> On Mon, Jan 15, 2018 at 1:46 PM, Dimuthu Leelarathne 
> wrote:
>
>>
>>
>> On Mon, Jan 15, 2018 at 1:32 PM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi All,
>>>
>>> Please consider the below scenario.
>>>
>>>
>>> ​
>>>
>>>
>>> When the Federated IdP sends the logout request we have to logout the
>>> user from the WSO2IS.  The proposed POC is as follows.
>>>
>>> - 1 & 4 are OAuth flows
>>> - 2 & 3 are SAML flows
>>>
>>> Participants of the discussion: Malithi, Thanuja and Dimuthu
>>>
>>> For the POC we will do the following.
>>>
>>> a) - At number 4 in the diagram, i.e. at the conclusion flow, we
>>> implement a listener that would record the SAML session Index vs. session
>>> Id in an appropriate data structure (for the POC it is a map). This handler
>>> will be in the out-boud SAML component.
>>>
>>> b) - At number 5 in the diagram, i.e. when the logout request is
>>> received, we  wrap the request and response and send over to our
>>> common-auth servelet. Here before invoking the common-auth servelet, we
>>> will retrieve session Id from the map (using the SAML Session Index) and
>>> set it in the wrapper object.
>>>
>>> @Thanuja and Malithi: Please add anything that I have missed. And also
>>> appreciate code snippets for above (a) and (b).
>>>
>>> After the POC implementation, we will have another review.
>>>
>>> thank you,
>>> Dimuthu
>>>
>>> --
>>> Dimuthu Leelarathne
>>> Director, Solutions Architecture
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: dimut...@wso2.com
>>> Mobile: +94773661935 <077%20366%201935>
>>> Blog: http://muthulee.blogspot.com
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935 <+94%2077%20366%201935>
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With Regards,
>
> *Rasika Perera*
> Senior Software Engineer
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> 
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Get rid of java2wsdl, wsdl2java sh/bat scripts from IS 5.5.0 bin directory

[Asela Pathberiya]

On Thu, Jan 11, 2018 at 7:52 AM, Sagara Gunathunga  wrote:

> IS bin directory contains following set of sh/bat files, ATM these are
> exists due to historical reasons only couldn't find any real usage. If
> there is no objection I would like to discard them from 5.5.0 WDYT ?
>
> java2wsdl.sh
> java2wsdl.bat
> wsdl2java.bat
> wsdl2java.sh
>
tcpmon-1.0.jar
> tcpmon.sh
> tcpmon.bat
>

+1  When it comes to WSO2IS,  i do not see any special use of above tool.
 But  tcpmon may be useful to tract the back channel HTTP calls. (But
WSO2IS usually uses HTTPS)

Thanks,
Asela.

>
>
> Thanks !
> --
> Sagara Gunathunga
>
> Director; WSO2, Inc.;  http://wso2.com
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
> Mobile : +9471 <+94%2071%20565%209887>2149951
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] WSO2 Identity Server 5.4.0 Beta Released !!!

[Asela Pathberiya]

On Fri, Dec 1, 2017 at 10:57 PM, Jayanga Kaushalya 
wrote:

> The WSO2 Identity and Access Management team is pleased to announce the
> release of WSO2 Identity Server 5.4.0 Beta.
>
> You can build the distribution from the source tag,
>
> Runtime: https://github.com/wso2/product-is/releases/tag/v5.4.0-beta
> Analytics: https://github.com/wso2/analytics-is/releases/tag/v5.4.0-beta
>
> following the steps given 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 the source,
>   - For the Runtime: Get a clone from https://github.com/wso2/p
>   roduct-is.git and checkout to v5.4.0-beta tag or you can directly
>   download the source for the tag from https://github.com/wso2/p
>   roduct-is/releases/tag/v5.4.0-beta
>   
>   - For the Analytics: Get a clone from https://github.com/wso2/
>   analytics-is.git and checkout to v5.4.0-beta tag or you can
>   directly download the source for the tag from
>   https://github.com/wso2/analytics-is/releases/tag/v5.4.0-beta
>   
>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-beta.zip binary distribution in
>   product-is/modules/distribution/target directory.
>   - wso2is-analytics-5.4.0-beta.zip binary distribution in
>   analytics-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 Beta release.
>

What is reason for following two sections patch & bug.  What is the
difference ?

Thanks,
Asela.


>
>
> Patch
>
>- [IDENTITY-6198 ] - IS
>Authentication Flow Behavior Between Multiple Service Providers Not Handled
>- [IDENTITY-6924 ] - Add
>ability to sign SAML response using different key other than the private
>key defined in the primary keystore in the carbon.xml
>- [IDENTITY-6931 ] -
>Adding logout support for outbound WS-Federation(Passive)
>- [IDENTITY-6988 ] -
>ClientAuthHandler configuration in identity.xml only read last property in
>OAuthServerConfiguration
>
> Bug
>
>- [IDENTITY-2861 ] -
>Receive fault response from RemoteClaimManagerService
>- [IDENTITY-4331 ] - When
>you add Google Prov Connector in a SP OB Provisioning Configuration
>section, You cannot edit IDP again. Lead to a blank page and NPE
>- [IDENTITY-4655 ] -
>Google provisioning not working with IS 5.2.0 beta
>- [IDENTITY-4968 ] -
>Subject claim is returned in the incorrect format when subject claim uri is
>added/removed
>- [IDENTITY-5154 ] - When
>select Domain as PRIMARY Count users always set to -1
>- [IDENTITY-6102 ] -
>System claims can be modified by the User
>- [IDENTITY-6118 ] - Some
>properties of a Custom Inbound Authenticator is not displaying in UI
>properly
>- [IDENTITY-6286 ] - OIDC
>- Wrong claim value in ID token when multiple IDPs used through federated
>authentication
>- [IDENTITY-6345 ] - Ask
>passoword with management console (SOAP service)not working
>- [IDENTITY-6350 ] -
>Account gets locked even if the fails are not consecutive
>- [IDENTITY-6352 ] -
>cannot edit existing workflow without changing workflow name
>- [IDENTITY-6353 ] -
>cannot disable workflow engagements
>- [IDENTITY-6355 ] -
>secondary roles are not displayed when creating workflows in tenant mode
>- [IDENTITY-6361 ] -
>NumberFormatException with server startup with Oracle
>- [IDENTITY-6369 ] -
>Intermittent error when login in to dashboard after some idle time
>- [IDENTITY-6371 

[Architecture] Proper way to clean up entries in token & session tables

[Asela Pathberiya]

Hi IAM/APIM team,

We have already seen that large number of table entries in OAuth2 access
token table ,  OAuth2 authorization code table  & IDN  session data tables
are causing issues in production system.

Sometime these tables contain around 10m entries.  Most of entries are
expired or invalid. We do not have a proper way to clean up those
expired/invalid entries.  There is a clean task for IDN session data tables
but it causes for deadlock when there are high load in the live system.

Following are the few suggestions for these three tables.  If we can figure
out the proper way, we can implement it in same manner for above.

This would probably help to keep a continue performance of the product
system.

1.  Having a periodical cleanup task inside our servers   (This is already
there for IDN session data)

-> Run from single node
-> Deadlock/Slowness can be generated with high load
->  Deadlock recovery can be built inside the code (OAuth2 is already
having it)

2. Having a con job based cleanup task.

-> Same as above but can run pre-defined time (when only load is low or
weekends)

3. Stored procedure  (This is already there for OAuth2 Access token)

-> Need for script for all the database type
-> Need to run/maintain separately (manual task)

4. Splitting/partition entries in to multiple tables when it is stored.

-> May be based on index of access token / session id
-> May be based on status (token status)

5. Moving non-active tokens or inactive session data in to separate table
(if there are required for auditing)


Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [IAM] Restful API to Evaluate Permission Tree in IS

[Asela Pathberiya]

On Wed, Oct 4, 2017 at 7:14 PM, Johann Nallathamby  wrote:

> Hi IAM Team,
>
> Currently we don't have $subject. What we have currently are two APIs.
>
> 1. RemoteAuthorizationManagerService.isUserAuthorized(user, resource,
> action) - a SOAP API that evaluates the permission tree.
>
> 2. XACML3.0 Rest/JSON API - a Restful API which takes a JSON payload and
> evaluates the XACML3.0 policies in the PDP.
>
> What we need to have is a Restful API to evaluate the permission tree, so
> that users can add their application permissions using the Service Provider
> UI in IS, and evaluate them by calling the Restful API from their
> application. Rather than innovating our own Rest API to do this, the best
> way would be using the XACML3.0 Rest API, because it conforms to an
> industry standard.
>
> Therefore what I am proposing is to have XACML3.0 policy shipped with IS
> 5.4.0 which will be used to evaluate the permission tree. Some of the
> considerations when designing this policy.
>
> a. A permission is the combination of resource + action. Both resource and
> action are defined attribute categories in XACML3.0. Therefore we don't
> need to define a new category for this.
>
> b. If we use the same category "Resource" to identify resources in the
> permission tree, as well as any other resources defined in any other
> policies, we may not be able to exclusively evaluate permission tree only,
> or exclusively evaluate the other policies which don't need permission
> tree. The solution for this would be to have a policy target which matches
> the action "ui.execute", which is the constant action for all our UI
> permissions, or a policy target that checks for resource startwith
> "/permission/" because all our UI permissions start with "/permission".
>
> Attached is the kind of policy I am having in mind. We can define a new
> XACML function to evaluate permission tree, that takes two arguments,
> subject-id and resource-id. This XACML function will internally invoke the
> AuthorizationManager.isUserAuthorized() OSGi service and return the
> result.
>
> Comments and suggestions are welcome.
>

+1   This look likes a simple approach to support a standard RESTful API
for application authorization with our permission tree.

Thanks,
Asela.


>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [IAM] Adding/Reloading X509 Certificates at Runtime without Restart

[Asela Pathberiya]

On Sat, Sep 9, 2017 at 11:57 AM, Johann Nallathamby  wrote:

> Hi IAM Team,
>
> The current keystore management functionalities of Carbon Server are
> provided by the security-mgt bundle. The features include,
>
>- Adding new key stores
>- Adding/Removing certificates to key stores (including the carbon
>server default key store)
>
> For the admin user the UI displays the carbon server key store
> (wso2-carbon.jks by default). The certificates and private key in this key
> store is used to sign and verify SSO requests etc. Additionally the server
> comprises of a trust store (client-truststore.jks by default) that is used
> to verify hosts (much like a web browser verifies websites) - this trust
> store is used during processes like OpenID Connect to verify the identity
> of authorization server etc.
>
> Current Limitations include:
>
>- Client-truststore.jks is not displayed on the UI - so if one needs
>to add certificates to the trust store one will have to do it externally
>[1].
>- There is no option to add additional trust stores - only key stores
>that includes a private key are allowed to be added.
>- In order for the changes to take effect the server needs to be
>restarted. [1]
>
> As the solution we have to:
>
>- Alter UI to view the default trust store
>- Alter keystore management service to support the addition of trust
>stores
>
> Why do we need multiple trust stores  support?

>
>- Create a X509TrustManager implementation that dynamically reloads
>any changes made to the trust store. Anyone using this
>"DynamicX509TrustManager" with SSLContext will not require to restart the
>server for changes to client trust store to take effect.
>
> Sorry!  It is not clear how do we feed this changes to HTTP client
implementation Does it require to change all the places which uses HTTP
client ?



> Above changes were made on pull request [2].
>

> Why we couldn't merge this feature earlier was that we hadn't developed a
> solution to sync this change from node to all nodes in the cluster. At the
> time of this development our syncing mechanism was primarily svn based
> deployment synchronization. However now we recommend deployment
> synchronization as the last option. Our preferred options are NFS file
> mount and r-sync. In such cases syncing is taken care by the
> infrastructure. So this solution seems to be good enough. This is the same
> case with secondary user stores as well.
>
> Although this use case is more prevalent in products such as ESB or API
> Manager, in IS I see following use cases.
>
> 1. Connecting to a LDAP backend via over SSL.
> 2. Connecting to a HTTP backend over SSL/TLS. E.g. OpenID Connect Token
> Endpoint call
> 3. Provisioning connectors (SCIM, DuoSecurity, etc.)
> 4. Connecting to 3rd party SMS services. E.g. Nexmo.
>
> Is this something we see valuable that can be added to IS 5.4.0 or 5.5.0?
>
> [1] https://wso2.org/jira/browse/IDENTITY-1131
> [2] https://github.com/wso2/carbon-identity/pull/1511
>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Question on load-balancing

[Asela Pathberiya]

On Mon, Sep 11, 2017 at 9:31 PM, Dave Florek 
wrote:

> Hi,
>
> I'm trying to achieve load-balancing on WSO2 Identity Server and need some
> help understanding the documentation and what my options are.
>
> I came across this article (https://docs.wso2.com/display/IS540/Clustered+
> Deployment) stating WSO2 needs a central database to manage all the WSO2
> IS front-ends. Is there a way to get around this and just have multiple
> WSO2 IS instances up with local databases to sync information to those
> local databases instead of one centralized database?
>

Is there any specific reason to have a local database for each instance
(except local registry).  Are those nodes are deployed in different data
centers  ?

Basically if databases can be properly synced, then you can deployed the
WSO2IS in such a way.  Data syncing is handled at database level & there
would not be involvement with WSO2IS.WSO2IS just reads/writes data & if
it is available at right time, there would not be an issue with deploying
like that.

However,  we are not usually recommending to deployed cluster nodes in
multiple data centers.

Thanks,
Asela..

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


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [APIM][C5] Shall we add gateway health check capability

[Asela Pathberiya]

On Wed, Sep 20, 2017 at 6:35 PM, Lakmal Warusawithana 
wrote:

> +1, this should go with v3.
>
> On Wed, Sep 20, 2017 at 1:08 PM, Pubudu Gunatilaka 
> wrote:
>
>> Hi,
>>
>> Shall we prioritize this feature and add this to APIM 3.0.0 GA? IMO, this
>> is more useful to have as we have more focus towards containers.
>>
>
What is our final decision. Is this a just a simple API which returns a 200
OK or some further metrics ?

Btw it is assumed that we are using Version service which is shipped with
all the product to check the health check currently.

Yes. This API would not be exposed to external network, therefore it is not
needed to worry about such attacks.

Thanks,
Asela.


>
>> Thank you!
>>
>> On Sat, Apr 1, 2017 at 11:35 AM, Bhathiya Jayasekara 
>> wrote:
>>
>>>
>>> On Mon, Mar 27, 2017 at 8:48 PM, Imesh Gunaratne  wrote:
>>>


 On Wed, Feb 1, 2017 at 12:24 PM, Nuwan Dias  wrote:

>
> 2) The gateway interceptors should ignore requests to this endpoint.
> i.e, security, throttling, analytics, etc should be ignored.
>

 Wouldn't this allow to perform DoS attacks on the gateway if no
 interceptors are applied? May be we would at least need a curcuit breaker
 for this endpoint to avoid such attacks. WDYT?

>>>
>>> Do we really need to consider this here as this special API does not
>>> call anything beyond the gateway? IMO we don't have to.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>>

 Thanks
 Imesh


> Thanks,
> NuwanD.
>
> On Wed, Feb 1, 2017 at 12:05 PM, Rushmin Fernando 
> wrote:
>
>> +1
>>
>> Other than sending back 200, I think it would be helpful if there is
>> another configuration to make the health check API, call a given backend
>> (which returns 200) and respond to the original caller.
>>
>> The advantage of having this is, we can have a rough idea about the
>> full flow. e.g. is traffic going out from the gateway node to outside
>> networks?
>>
>> On Wed, Feb 1, 2017 at 11:44 AM, Lakmal Warusawithana <
>> lak...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> When we deploying api gateway in container management system (or
>>> even fronted by ELB) we need to have a health check end point to 
>>> configure.
>>> Since gateway only going pass through we don't have such at the moment.
>>>
>>> Shall we do $subject? it should only return 200
>>>
>>> thanks
>>>
>>> --
>>> Lakmal Warusawithana
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692 <+94%2071%20428%209692>
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>
>> mobile : +94775615183
>>
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 *Imesh Gunaratne*
 Software Architect
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
 W: https://medium.com/@imesh TW: @imesh
 lean. enterprise. middleware


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


>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com *
>>>
>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> *
>>> *Twitter: https://twitter.com/bhathiyax *
>>> *Blog: http://movingaheadblog.blogspot.com
>>> *
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Senior Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> Lakmal Warusawithana
> Senior Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692 <+94%2071%20428%209692>
> Blogs : https://medium.com/@lakwarus/
> http://lakmalsview.blogspot.com/
>
>
>
> ___

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Asela Pathberiya]

On Mon, Sep 18, 2017 at 6:03 PM, Thilina Madumal 
wrote:

> Hi all,
>
>
> On Mon, Sep 11, 2017 at 11:28 AM, Dulanja Liyanage 
> wrote:
>
>>
>>
>> On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna 
>> wrote:
>>
>>> HI,
>>>
>>> On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby 
>>> wrote:
>>>
 IAM Team,

 Currently we don't have a exclusive permission to login to the user
 portal; we use "/permission/admin/login". I think we need to have a
 dedicated permission for that. Why?

 1. No way to allow users to login to user portal but restrict users
 from logging in to management console.

 2. We could give this new permission to "INTERNAL/everyone" role. So
 that any new users added to the system, via admin console, SCIM, Self
 sign-up or JIT provisioning, will be able to login to the user portal. If
 we don't want that we can simply take off that permission from the
 "INTERNAL/everyone" role.

 I could think of further improving 2 above, by having separate roles
 for each of the following scenarios.
 a) Admin created users (Resident SP) - one role for all
 b) JIT provisioned users - one role per IdP
 c) Self signup users - we already have "selfsignup" role from IS
 5.3.0 onwards.
 d) External service provider created users via SCIM - one role per
 SP
 All the above roles can have the new permission, and selectively taken
 off if not needed. In addition we can use these roles to manage permissions
 for these well known groups of users who came from the same source.

 I stumbled upon this issue when I was trying to do "Email verification
 and password request" scenario. Once I click the link in the email that was
 sent to my inbox, and confirm, and update my new password and confirm it, I
 was sent to the user portal to login. But since I didn't have the required
 authorization setup I failed to login. Bit of a bad user experience there.

 Shall we try to introduce a new permission for user portal and give it
 by default to "INTERNAL/everyone" for IS 5.4.0?

>>> -1 for giving permission to  "INTERNAL/everyone"
>>> INTERNAL/everyone is a virtual Role that used to represent all users.
>>> for example all the federated users also considered as users in
>>> INTERNAL/everyone Role.
>>>
>>> Yes, me too -1 for using "INTERNAL/everyone" for this.
>>
>>
>>> But agree with johan for having different permission for dashboard
>>> login. And better if system admin do it manually.
>>>
>>
>> I don't think this should be a manual task, because it will be tedious.
>> IMO there should be a separate dedicated role to access the Dashboard with
>> the new permission as mentioned by Johann - like the Subscriber role in AM
>> - and in the user provisioning points, new users should be automatically
>> added to that role depending on some configuration done by the admin.
>>
>
> +1
>
> IMO to make this role more flexible following things should be enforced;
>
>1. Should have a seperate permission for dashboard login. But it
>should allow only dashboard login nothing else.
>2. For other admin services that can be invoked from the dashboard
>should have seperate set of fine grained permissions such that system
>administrator can revoke permission as necessary from that role to allow
>only a desired set of services.
>
>
Did we fix this in 5.4.0 ?

Is it by introducing a new role  ?   When user is self registered or
provisioned,  Is user default added in to this role ?

Thanks,
Asela.


>
>>
>>> And there is another concern with the permission, from the dashboard we
>>> are invoking several admin services  so those services also should work
>>> with this new permission.
>>>
>>> Thanks,
>>> Ishara
>>>
>>>
 Thanks & Regards,
 Johann.

 --

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

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

>>>
>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Associate Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791 <071%20799%206791>
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Dulanja Liyanage
>> Lead, Platform Security Team
>> WSO2 Inc.
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
> Thaks and Regards,
> Thilina.
>
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  

Re: [Architecture] [APIM] Supporting Thrift protocol for GW-KM communication with Load Balancing

[Asela Pathberiya]

On Fri, Sep 1, 2017 at 2:26 PM, Lakmal Warusawithana 
wrote:

> Hi Asela,
>
> From APIM v3, we are going to use standard IS. That mean, thrift will not
> support from v3 onward. Since we have WSClient option is supported in the
> current APIM and recommended in load balance scenario, IMO fixing this will
> not get huge advantages.  If we want to fix, #2 will be the easy option.
>
> WDYT?
>
>
Yes it is fine.

Also WSO2IS can probably expose a key validation using thrift, if it can
provide better performance figures

@IS team any thoughts on this ?

Thanks,
Asela.


> thanks
>
> On Fri, Sep 1, 2017 at 12:55 PM, Asela Pathberiya  wrote:
>
>> Hi APIM team,
>>
>> According to the docs; We are not recommending the thrift protocol to
>> communicate with GW and KM when even TCP load balancer is used.
>>
>> The problem is that;  thrift connection must be authenticated & thrift
>> session is not replicated among key manager nodes.
>>
>> IMO; we have three solution for this.
>>
>> 1.  Replicate thrift session in KM nodes
>>
>> 2.  Client side load balancing
>>
>> 3. Sending authentication credentials from GW to KM in every request.
>> This has been implemented in WSO2IS for XACML PDP.  You can find the
>> details [1] & sample thrift client [2]
>>
>> We can easily implement approach 3,  Shall we consider this for next APIM
>> release ?
>>
>> [1] http://xacmlinfo.org/2014/04/11/thrift-load-balancing/
>> [2] https://svn.wso2.org/repos/wso2/people/asela/xacml/pep/thrift-LB
>>
>> Thanks,
>> Asela.
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
> Lakmal Warusawithana
> Senior Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692 <+94%2071%20428%209692>
> Blogs : https://medium.com/@lakwarus/
> http://lakmalsview.blogspot.com/
>
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

[Architecture] [APIM] Supporting Thrift protocol for GW-KM communication with Load Balancing

[Asela Pathberiya]

Hi APIM team,

According to the docs; We are not recommending the thrift protocol to
communicate with GW and KM when even TCP load balancer is used.

The problem is that;  thrift connection must be authenticated & thrift
session is not replicated among key manager nodes.

IMO; we have three solution for this.

1.  Replicate thrift session in KM nodes

2.  Client side load balancing

3. Sending authentication credentials from GW to KM in every request.  This
has been implemented in WSO2IS for XACML PDP.  You can find the details [1]
& sample thrift client [2]

We can easily implement approach 3,  Shall we consider this for next APIM
release ?

[1] http://xacmlinfo.org/2014/04/11/thrift-load-balancing/
[2] https://svn.wso2.org/repos/wso2/people/asela/xacml/pep/thrift-LB

Thanks,
Asela.


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] IS Authentication Flow Behavior Between Multiple Service Providers

[Asela Pathberiya]

On Fri, Jul 14, 2017 at 11:31 AM, Harsha Kumara  wrote:

> Hi All,
>
> This is regarding the behavior of Authentication flow between multiple
> service providers.
>
> I have created two service providers with following configurations.
>
> *SP1*
>
> This service provider has two options which allow to users to login either
> Basic Authentication scheme or Facebook
>
> Configuration
>
> 1 Authentication Step with MultiOption with Basic Auth and Facebook.
>
>
> *SP2*
>
> This service provider has two authentication steps which allow to users
> to login either Basic Authentication scheme or Facebook and second
> authentication step with TOTP.
>
> Configuration
>
> 2 Authentication Steps
>
>- 1 Authentication Step with MultiOption with Basic Auth and Facebook.
>- 2 Authentication Step with TOTP
>
>
> *Behavioral Concern*
>
> I have configured two applications with SP1 and SP2 respectively. Then I
> have logged into the first application with Basic Authentication Scheme
> which is configured in SP1.
>
> But when I going to authentication with my second application which
> configured with SP2, I have logged into it automatically.
>
> Shouldn't it ask for TOTP authentication? Because first application only
> authenticated with Basic Auth but my second application required Basic Auth
> + TOTP.
>

Yes. It should...  Session contains the authenticated SP details.
Therefore;  it can decide based on the SP...  If it is not working,  it
seems like a bug..

Thanks,
Asela.


>
> Thanks,
> Harsha
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Force Delete Identity Providers

[Asela Pathberiya]

On Wed, May 31, 2017 at 2:38 PM, Prabath Siriwardena 
wrote:

>
>
> On Wed, May 31, 2017 at 1:16 AM, Asela Pathberiya  wrote:
>
>>
>>
>> On Mon, May 29, 2017 at 11:12 AM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 17, 2017 at 9:44 AM, Prabath Siriwardena 
>>> wrote:
>>>
>>>> At the moment we can't delete an identity provider, if its associated
>>>> with one or more service providers.
>>>>
>>>> Also - for the user there is no way to find out the associated service
>>>> providers for a given identity provider - without going through each and
>>>> every service provider config.
>>>>
>>>
>>>
>>> If we allow to delete the current IDP means, we are going to reset the
>>> SP association to the defaults which are already associated with this IDP.
>>>
>>> Then anyway they have to go and select the new IDP.
>>>
>>> But in that case, it would be hard to find which is the one earlier set
>>> to that deleted IDP, right ?
>>>
>>> Once we delete the IDP, we can't provide automate solution or prompt for
>>> each to select what would be the next option to that step because of there
>>> are lot of SPs.
>>>
>>> I think, in practically, it is first create new IDP and change the SPs
>>> to that. Then they can decide to delete the current IDP.
>>>
>>> ​Yes as a feature, +1 to have this delete functionality. ​
>>>
>>
>>
>> IMHO;  Spending cycles on this feature may not be much useful..  IDP may
>> like a user store..  In real production,  it is very rare to remove an IDP
>> from the WSO2IS.  What may be happened;  IDP would be removed from the
>> associated to SP.
>>
>
> 1. How do you handle a scenario in a test environment where you have 50+
> service providers and want to delete an Identity Provider?
>

If it is test env,  we can just keep it as it is without delete..or you
even can edit it..


> 2. How do you handle a scenario where you expose IS to your customers to
> create their own identity providers and SPs - just like Identity Cloud?
>

Usually; before you move to cloud it may be tested in test tenant &
verify..  In production tenant, it is rare to delete it..

I meant that we need some the delete feature... it is fine.. :)   But; it
is not a feature to prioritize for recent IS releases.  IMHO; There
probably must be important improvements/features than this & there is no
any important/critical production use cases.

Thanks,
Asela.


>
> Thanks & regards,
> -Prabath
>
>
>>
>> Can someone please explain what is the critical of this feature for given
>> production WSO2IS step ?  Currently  -1 for prioritizing this for IS
>> releases.
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
>>>>
>>>> This is fine (or just okay) if we have 2 or 3 service providers in the
>>>> system - but its not the case today.
>>>>
>>>> Can we provide a feature to force delete an identity provider? If not
>>>> at the UI - at least at the API level..
>>>>
>>>> If we agree - can we please prioritize this...?
>>>>
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>> Twitter : @prabath
>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>>
>>>> Mobile : +1 650 625 7950 <(650)%20625-7950>
>>>>
>>>> http://facilelogin.com
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950 <(650)%20625-7950>
>
> http://facilelogin.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Force Delete Identity Providers

[Asela Pathberiya]

On Mon, May 29, 2017 at 11:12 AM, Harsha Thirimanna 
wrote:

>
>
> On Wed, May 17, 2017 at 9:44 AM, Prabath Siriwardena 
> wrote:
>
>> At the moment we can't delete an identity provider, if its associated
>> with one or more service providers.
>>
>> Also - for the user there is no way to find out the associated service
>> providers for a given identity provider - without going through each and
>> every service provider config.
>>
>
>
> If we allow to delete the current IDP means, we are going to reset the SP
> association to the defaults which are already associated with this IDP.
>
> Then anyway they have to go and select the new IDP.
>
> But in that case, it would be hard to find which is the one earlier set to
> that deleted IDP, right ?
>
> Once we delete the IDP, we can't provide automate solution or prompt for
> each to select what would be the next option to that step because of there
> are lot of SPs.
>
> I think, in practically, it is first create new IDP and change the SPs to
> that. Then they can decide to delete the current IDP.
>
> ​Yes as a feature, +1 to have this delete functionality. ​
>


IMHO;  Spending cycles on this feature may not be much useful..  IDP may
like a user store..  In real production,  it is very rare to remove an IDP
from the WSO2IS.  What may be happened;  IDP would be removed from the
associated to SP.

Can someone please explain what is the critical of this feature for given
production WSO2IS step ?  Currently  -1 for prioritizing this for IS
releases.

Thanks,
Asela.


>
>
>
>>
>> This is fine (or just okay) if we have 2 or 3 service providers in the
>> system - but its not the case today.
>>
>> Can we provide a feature to force delete an identity provider? If not at
>> the UI - at least at the API level..
>>
>> If we agree - can we please prioritize this...?
>>
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +1 650 625 7950 <(650)%20625-7950>
>>
>> http://facilelogin.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [IS] IS 5.5.0 += Adaptive Authentication

[Asela Pathberiya]

On Wed, May 31, 2017 at 10:38 AM, Ruwan Abeykoon  wrote:

>
> Hi Prabath,
>
>
>> Please check whether my understanding is correct based on the following
>> mail..
>>
>> 1. We define set of ACR values at the framework level - which are
>> agnostic to the inbound protocols.
>> 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values -
>> but must be mapped to the ACR values defined at the framework level.
>> 3. Each ACR value will represent a set of authenticators (or steps) - I
>> guess your Table-2 is representing that.
>>
> Yes.
>
>
>
>> 1. If you take OIDC as an example, you can send multiple acr_values in
>> the request (space separated - and by preference). I would suggest the
>> protocol specific component will pick one out of that - and will pass the
>> mapped ACR value to the framework - and the same will be included in the
>> response as the value of the acr parameter.
>> 2. Once the user is authenticated, the framework will return back the
>> authenticators used in each step. Once again the protocol specific
>> component has to match these to corresponding AMR values and send back to
>> the service provider.
>>
>> Few suggestions..
>>
>> 1. IMO we should let each service provider define multiple authentication
>> chains - and one would be the default one (so this will not break the
>> current behavior).
>> 2. Each chain can be associated with one or more ACR values.
>> 3. Right now the authentication chain corresponding to a service provider
>> is loaded by its name. But with this design it will be by the name and the
>> ACR value.
>>
>
> I will change the architecture with above suggestions.
>

Yes +1 above changes.   IMO;  If we are going to achieve actual adaptive
authentication, we may need to specially consider about the end user.
First end user must be validated & based on the user, we may need to decide
the authenticators & also the based on the first steps,  second step must
be decided.

However;  I assume that still we have above interface to extend & decide
the given authentication chains in customer manner (without the SP given
ACR)

Thanks,
Asela.


>
>
>>
>> This will require minimal changes at the framework level.
>>
>> Also - let's keep adaptive authentication out of this. We can address
>> that separately - and I don't think we need to have it for IS 5.5.0.
>>
>> Noted. I will create new mail thread specific to ACR and AMR and continue
> discussion with updated architecture.
>
> Cheers,
> Ruwan
>
>
> On Wed, May 31, 2017 at 3:59 AM, Prabath Siriwardena 
> wrote:
>
>> Hi Ruwan,
>>
>> Please check whether my understanding is correct based on the following
>> mail..
>>
>> 1. We define set of ACR values at the framework level - which are
>> agnostic to the inbound protocols.
>> 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values -
>> but must be mapped to the ACR values defined at the framework level.
>> 3. Each ACR value will represent a set of authenticators (or steps) - I
>> guess your Table-2 is representing that.
>>
> Few other things I assume we should be doing (not clearly mentioned in the
>> mail)..
>>
>>
>
>> 1. If you take OIDC as an example, you can send multiple acr_values in
>> the request (space separated - and by preference). I would suggest the
>> protocol specific component will pick one out of that - and will pass the
>> mapped ACR value to the framework - and the same will be included in the
>> response as the value of the acr parameter.
>> 2. Once the user is authenticated, the framework will return back the
>> authenticators used in each step. Once again the protocol specific
>> component has to match these to corresponding AMR values and send back to
>> the service provider.
>>
>> Few suggestions..
>>
>> 1. IMO we should let each service provider define multiple authentication
>> chains - and one would be the default one (so this will not break the
>> current behavior).
>> 2. Each chain can be associated with one or more ACR values.
>> 3. Right now the authentication chain corresponding to a service provider
>> is loaded by its name. But with this design it will be by the name and the
>> ACR value.
>>
>> This will require minimal changes at the framework level.
>>
>> Also - let's keep adaptive authentication out of this. We can address
>> that separately - and I don't think we need to have it for IS 5.5.0.
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Thu, May 25, 2017 at 12:34 AM, Ruwan Abeykoon  wrote:
>>
>>> Hi All,
>>> I plan to add the Adaptive authentication on IS. Please provide your
>>> feedback on the architecture bellow.
>>>
>>> References:
>>> http://openid.net/specs/openid-connect-core-1_0.html#Authori
>>> zationEndpoint
>>> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02
>>>
>>>
>>> Architecture
>>>
>>> *    Figure 1:
>>> Framework and Endpoints  Authentication Context Class Reference(ACR)*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Different protocols may su

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

[Asela Pathberiya]

On Wed, May 31, 2017 at 1:08 PM, Farasath Ahamed  wrote:

>
> On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi Dinali,
>>
>> Consider the following calculation.
>>
>> expiry time = issuedTimeInMillis + validityPeriodMillis -
>> (System.currentTimeMillis() - timestampSkew)
>>
>> So actually token is valid for (validityPeriodMillis + timestampSkew)
>> seconds. This additional time is added to avoid the error occurred due to
>> the time synchronization issues between servers.
>>
>> If your servers are perfectly synced then you can use timestampSkew
>> value as 0.
>>
>
> If we do not have any reasoning behind this 300s value the shouldn't our
> default value be 0 as Dinali has suggested?
>

Yes.  Best practice is to syn server's time properly.  +1 keeping  0 as the
default value..


>
>
>> Thanks,
>> Thanuja
>>
>>
>> On Wed, May 31, 2017 at 12:01 PM, Dinali Dabarera 
>> wrote:
>>
>>> Hi All,
>>>
>>> In our identity.xml the default timeStampScrew value is used as 300
>>> seconds. Shouldn't this be 0 seconds?
>>>
>>> Because when we are getting a token from password grant type again and
>>> again *without a time delay*, the expiry time of the token
>>> increases than its accepted value because of this equation we are using.
>>>
>>> expiry time = issuedTimeInMillis + validityPeriodMillis - (System.
>>> currentTimeMillis() - timestampSkew);
>>>
>>> Since timestampSkew = 300 seconds, validityPeriodMillis = 3600 seconds,
>>> therefore, expiry time = 3644 seconds which can not be happened.
>>>
>>> Therefore, it is better to have the default timeStampScrew value as 0
>>> seconds in order to get correct results.
>>>
>>>
>>> Thanks!
>>>
>>> --
>>> *Dinali Rosemin Dabarera*
>>> Software Engineer
>>> WSO2 Lanka (pvt) Ltd.
>>> Web: http://wso2.com/
>>> Email : gdrdabar...@gmail.com
>>> LinkedIn 
>>> Mobile: +94770198933 <+94%2077%20019%208933>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Associate Technical Lead
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [APIM][C5] SSO Feature for Publisher/Store Login

[Asela Pathberiya]

On Wed, May 24, 2017 at 12:11 PM, Roshan Wijesena  wrote:

>
> On Wed, May 24, 2017 at 1:19 AM, Bhathiya Jayasekara 
> wrote:
>
>> 1. How do you configure this IDPs other than WSO2 identity server
>>
>
> This is a good question, what if other IDP does not support OIDC?  any
> other solution for SSO? What happened to SAML are we not supporitng it?
>

We need to support both SAML2 & Openid Connect...  Still SAML2 SSO is
mostly used... we can not just remove it...

Thanks,
Asela.


>
>
>> 2. How do you handle logout ?
>
>
> Can't we send a revoke token request when logout and do a page refresh
> after succesfull revoke.
>
>
>
>
> --
> Roshan Wijesena.
> Senior Software Engineer-WSO2 Inc.
> Mobile: *+94719154640 <+94%2071%20915%204640>*
> Email: ros...@wso2.com
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna  wrote:

>
>
> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
>>>> wrote:
>>>>
>>>>>
>>>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>>>>
>>>>>> Hi Gayan,
>>>>>>
>>>>>> What are you trying to achieve by moving the client-secret validation
>>>>>> logic to the interceptor from the jax-rs layer?
>>>>>>
>>>>>
>>>>> ​Actually, we have separate layer to pass the secured API in IS and it
>>>>> is common service that can be used for any product. AppManager also using
>>>>> that.
>>>>> In here also Gayan is trying to get the security check into that
>>>>> common layer instead of allowing to go into the next level to validate
>>>>> headers.  ​
>>>>>
>>>>
>>>> Are we going to use common basic authentication handler  ?
>>>>
>>>
>>> ​This feature is already done in IS 5.3.0 as a common point to handle
>>> authentication and authorization per resources as in [1].​
>>>
>>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>>> ion-authorization-common.html
>>>
>>>>
>>>> BTW;  Client credentials can be received as url param..  Are we
>>>> validating them in here ?  If it is not;  Why are we introducing two
>>>> validation points for same ?
>>>>
>>>> ​If we have our own way to pass authentication details,​ then we have
>>> to write an authentication handler to that and register.
>>>
>>
>> This is according to the OAuth2 spec...  It meant that we need another
>> handler implementation to do it or can we use existing authentication
>> handler ?
>>
>
> ​What i meant was that we can write custom handler as well to here. ​
>
Yes.  if it is;  it must be shipped by default.


>
>
>
>>
>>
>>>
>>>
>>>
>>>> Actually I do not see much use of changing the current validation
>>>> model.
>>>>
>>> ​This is for all the APIs in IS to handle authentication/authorization
>>> in common way​ and decouple it with implementation of each.
>>>
>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Asela.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Since both run on the same JVM, doesn't the overhead of the process
>>>>>> remain the same, irrespective of where it runs?
>>>>>>
>>>>>> Thanks,
>>>>>> NuwanD.
>>>>>>
>>>>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> In Oauth /token endpoint and /revoke endpoint
>>>>>>>
>>>>>>> https://localhost:9443/oauth2/token
>>>>>>> https://localhost:9443/oauth2/revoke
>>>>>>>
>>>>>>> required authorization with client key, client secret in basic auth
>>>>>>> headers. Currently in implementation we validate those headers after
>>>>>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>>>>>> are unsecured. There is significant amount of processing happen even for
>>>>>>> wrong client secret.
>>>>>>>
>>>>>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
>>>>>>> to validate client credentials ? We may need to plug an additional
>>>>>>> authenticator to validate client key, client secret in basic auth 
>>>>>>> headers.
>>>>>>> This authenticator may conflict with basic authenticator because
>>>>>>> both authenticators validate basic auth credentials different way. There
>>>>>>> are two approaches to avoid the conflict.
>>>>>>>
>>>>>>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna  wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>>
>>>> Hi Gayan,
>>>>
>>>> What are you trying to achieve by moving the client-secret validation
>>>> logic to the interceptor from the jax-rs layer?
>>>>
>>>
>>> ​Actually, we have separate layer to pass the secured API in IS and it
>>> is common service that can be used for any product. AppManager also using
>>> that.
>>> In here also Gayan is trying to get the security check into that common
>>> layer instead of allowing to go into the next level to validate headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to handle
> authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/
> authentication-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we have to
> write an authentication handler to that and register.
>

This is according to the OAuth2 spec...  It meant that we need another
handler implementation to do it or can we use existing authentication
handler ?


>
>
>
>> Actually I do not see much use of changing the current validation model.
>>
> ​This is for all the APIs in IS to handle authentication/authorization in
> common way​ and decouple it with implementation of each.
>

>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
>>>> Since both run on the same JVM, doesn't the overhead of the process
>>>> remain the same, irrespective of where it runs?
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> In Oauth /token endpoint and /revoke endpoint
>>>>>
>>>>> https://localhost:9443/oauth2/token
>>>>> https://localhost:9443/oauth2/revoke
>>>>>
>>>>> required authorization with client key, client secret in basic auth
>>>>> headers. Currently in implementation we validate those headers after
>>>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>>>> are unsecured. There is significant amount of processing happen even for
>>>>> wrong client secret.
>>>>>
>>>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
>>>>> to validate client credentials ? We may need to plug an additional
>>>>> authenticator to validate client key, client secret in basic auth headers.
>>>>> This authenticator may conflict with basic authenticator because both
>>>>> authenticators validate basic auth credentials different way. There are 
>>>>> two
>>>>> approaches to avoid the conflict.
>>>>>
>>>>> *#option 01 *
>>>>> Increase the priority of newly added authenticator and check the
>>>>> context inside authenticator canHandle.
>>>>>
>>>>> *#option 01 *
>>>>> Increase the priority of newly added authenticator and check existence
>>>>> of oauth application from client key.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> --
>>>>> Gayan Gunawardana
>>>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>> Email: ga...@wso2.com
>>>>> Mobile: +94 (71) 8020933
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>> email : nuw...@wso2.com
>>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [C5] [APIM] Frnot End scope validation

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 1:11 PM, Ishara Karunarathna 
wrote:

> HI,
>
> On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias  wrote:
>
>> Yes, maintaining the mappings is not an issue AFAIS. The API definition
>> (Swagger) itself has the scope associated with each resource. So we just
>> need a way of storing the role(s) against each scope. By default the
>> product will have like say <10 scopes. So what we're looking at is a config
>> with the following format.
>>
>> {
>> "scopes": [{
>> "key": "apim:add_api",
>> "roles": ["creator", "admin"]
>> },
>> {
>> "key": "apim:add_application",
>> "roles": ["subscriber", "admin"]
>> }
>> ]
>> }
>>
>> The above config is only required by the server, to issue the token. What
>> the client (Browser) needs to render the buttons and links are the scopes
>> associated with the token and the API definition (Swagger).
>>
> If we are only using scops  and Roles, and if we are not going for
> finegrain level such as attribute base restriction on this APIs I think its
> ok to go with simple implementation.
> Which will be easy to implement and anyone  users will easily understand
> stuff.
>

+1

I just want to know about how we are defining the policies whether it is
based on standard approach such as XACML.  Yes.  we need to use scope at
protocol level & it is totally fine.

If policies are simple as just have some kind of mapping on role-scope..
 yes we can use it within API definition & do not want to make it more
complex.

But; it is always better; if we can have some externalizing point (some
kind of authorization handler/validator) in to the implementation which may
help to plug any authorization server/endpoint.

Thanks,
Asela.


>
>
> -Ishara
>
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 10:10 AM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias  wrote:
>>>
>>>> What's wrong with using OAuth2.0 scopes? The authorization requirements
>>>> are simply to define which role/group is permitted to access a given
>>>> resource. Which is very simply supported OOTB via scopes and the
>>>> configuration is very simple as well.
>>>>
>>>> One of the key design principles here is to keep things simple. Because
>>>> this is something almost all users of the product will be
>>>> configuring/tweaking when setting up a deployment for real. I don't think
>>>> everyone understands XACML. Besides, we do not need the extensive feature
>>>> set offered by XACML for this particular API.
>>>>
>>>> Another key design principle here is to make the API generic so that
>>>> anyone can easily write a UI using it. OAuth2.0 is the de facto security
>>>> standard for REST APIs and anyone using a REST API understands it (now). So
>>>> why move away from the standard? When developing an SPA type UI app, it is
>>>> extremely easy to render (or not) buttons/links when the resource is
>>>> protected via scopes. XACML makes that tougher. Actually I personally
>>>> haven't figured out how to render the html on the client side unless I
>>>> evaluate the XACML policy on the client side, which of course is nearly
>>>> impossible I guess.
>>>>
>>>> ​Our concern was not to say any wrong about the OAuth2 scopes. Only
>>> concern was we can use XACML for such a fine grained cases by getting its
>>> extensibility as well.​ Now we have JSON based RestAPI for XACML within IS
>>> as well.
>>> Yes I agree that OAuth 2 story is bit simple rather than using XACML.
>>> But anyway, you guys have to maintain the mapping somehow and as you said,
>>> it is also not such complicated to that.
>>>
>>>
>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 21 Apr 2017 5:27 p.m., "Asela Pathberiya"  wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray 
>>>>> wrote:
>>>>>
>>>>>> Hi Asela,
>>>>>>
>>>>>> What is reason for using scopes for authorization.. ?  Can't we use
>>>>>> policy based 

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it is
> common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that common
> layer instead of allowing to go into the next level to validate headers.  ​
>

Are we going to use common basic authentication handler  ?

BTW;  Client credentials can be received as url param..  Are we validating
them in here ?  If it is not;  Why are we introducing two validation points
for same ?

Actually I do not see much use of changing the current validation model.

Thanks,
Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>>> validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth headers.
>>> This authenticator may conflict with basic authenticator because both
>>> authenticators validate basic auth credentials different way. There are two
>>> approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the context
>>> inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check existence
>>> of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [C5] [APIM] Frnot End scope validation

[Asela Pathberiya]

On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray  wrote:

> Hi Asela,
>
> What is reason for using scopes for authorization.. ?  Can't we use policy
> based approach such as XACML ?
>
> Default authentication and authorization protocol we use is oauth, hence
> we already have support for scopes in our REST APIs.
> Therefore is it straight forward to use scopes as we just need to validate
> UI components and it is not required to add the complexities we can have
> from XACML.
>

What is the standard which defines the policies..  In scopes also;  you
need to store the authorization mapping in some where.. isn't it ?  Can't
we use XACML policies for that ?

>
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Apr 20, 2017 at 6:22 PM, Bhathiya Jayasekara 
> wrote:
>
>> Hi Ishara,
>>
>> Please see my comments inline.
>>
>> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray  wrote:
>>
>>> Hi,
>>>
>>> Previous versions(Before C5) of APIM Publisher, Store Apps front end
>>> validations were done based on user roles.
>>>
>>> But with C5 we think of fine graining User Interfaces by controlling
>>> access to UI components such as Add, Edit, Delete buttons/links based on
>>> the user scopes.
>>>
>>> 1. We need to find scopes associate with each action (REST api call).
>>> This can be done in two ways.
>>>
>>>- Read the scopes from swagger definition
>>>
>>>- Associate scopes with the UI component itself.
>>>
>>> IMO associate scopes with the UI component will be more efficient than
>>> processing swagger definition while rendering UI.
>>>
>>
>> Yes, on the other hand it'll be very hard to do this dynamically.
>>
>>
>>>
>>> 2. We need to find logged in user scopes and persists in somewhere
>>>
>>>- We can do a introspect call and get the user scopes.
>>>
>>>- We can get the roles from logged in user claims and then find
>>>scopes based on role to scopes mapping
>>>
>>> +1 for the 1st option. In the 2nd one, we're doing the same what
>> introspect service already does. So we don't have to do that again.
>>
>>> In both the cases we will need to persist these info in a browser
>>> session.
>>>
>> I believe, here you meant cookies, because in our webapps there won't be
>> a session, since ithey're completely client side apps.
>>
>>> persisting user claims will be helpful for future use cases as well.
>>>
>> I think there can be security issues of storing user claims in browser
>> cookies.
>>
>>> We can use a secure cookie with HttpOnly and Secure flags enabled to
>>> persist these data.
>>>
>> I don't think we can use HttpOnly here, because they can't be accessed by
>> JS.
>>
>>>
>>> *Implementation*
>>>
>>> There will be a common js function that accepts UI component and then it
>>> validates against user scopes. Based on that the UI component will be
>>> enabled/ disabled.
>>>
>>> Followings are the UI components that have identified to be validated
>>> among currently available UIs.
>>>
>>>
>>> *-Publisher-*
>>>
>>> 1.Create API
>>> 2. API - Edit
>>> 3. API - Delete
>>> 4.Change Policies - Update
>>> 5. Change Labels - update
>>> 6. Change LC status buttons
>>> 7. Endpoint Update
>>>
>> There will be "Endpoint - Add" too.
>>
>> Thanks,
>> Bhathiya
>>
>>> 8. Resource Add
>>> 9. Resource Save
>>> 10. Document Add
>>> 11. Document Edit/Delete
>>> 12. Create new version - Add
>>> 13. Access Controll - Not yet Available
>>> 14. Mediation - todo
>>> 15. Scripting - todo
>>>
>>> *-Store-*
>>> 1. Application - Add
>>> 2. application - View
>>> 3. application - Edit
>>> 4. application - Delete
>>> 5. Subscription - todo
>>>
>>> Appreciate your thoughts.
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185 <071%20547%208185>*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> *
>>
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933 <+94%2077%20762%205933>
 +358 449 228 979

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

[Architecture] Configure token expiry time based on the Service provider (APIM application)

[Asela Pathberiya]

Hi IS/APIM team,

Is $subject in our roadmap ?  This seems to be a required features.
Different applications may need the different user token expiry time based
on their security level.

Just heard that; IOT server may has already requirement with that;  It is
needed to define a token expiry level based on their device type.  Say;
 some device's token may be embedded & these token may have longer expiry
time (never expired).  Also;  some devices type need a  less expiry time
based on their security policies.   It is not sure how we are handled this
with APIM feature without $subject.   But;  this can be easily handled, if
we can have such feature inbuilt.

Thanks,
Asela


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933 <+94%2077%20762%205933>
 +358 449 228 979

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

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

[Asela Pathberiya]

On Thu, Apr 20, 2017 at 6:46 PM, Johann Nallathamby  wrote:

>
>
> On Thu, Apr 20, 2017 at 3:27 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 18, 2017 at 11:51 AM, Asela Pathberiya 
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 17, 2017 at 12:00 PM, Godwin Shrimal 
>>> wrote:
>>>
>>>> +1 to have separate keystores for secure vault & token signing. Any
>>>> reason/use case to have separate kesytores for each token signing ? Will it
>>>> not add more overhead on deployment and maintenance ? With the custom
>>>> inbound authenticator feature you can plug your own inbound authenticator
>>>> and then we have to think which token signing keystore we use ?
>>>>
>>>
>>> Usually one private key is enough for token signing.  But;  if SP/IDP
>>> restricts to use a privatekey which is signed by a given CA (custom CA),
>>>  we may need to configure more keystores..
>>>
>>>
>>>>
>>>>
>>>> Thanks
>>>> Godwin
>>>>
>>>> On Wed, Apr 12, 2017 at 5:58 PM, Asela Pathberiya 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> According to the current design;   KeyStore which is defined in the
>>>>> carbon.xml file is used for both secure vault & token signing
>>>>> (SAML/id_token) which is not a good design.  We need to keep that separate
>>>>> keystore for secure vault as it can not be modified.
>>>>>
>>>>> Also; To add more flexibility;  it is better to have separate keystore
>>>>> for each token signing.  I know we can extend & achieve this,  but default
>>>>> implementation would be great.
>>>>>
>>>>> Shall we add this to next WSO2IS release as this is a simple
>>>>> improvement ?
>>>>>
>>>>
>> Can someone confirm whether this is in WSO2IS road map ?
>>
>
> Are you referring to private key per SP or private key per inbound
> protocol?
>

Actually for now it is better to have separate keys for data encryption  &
all token signing regardless of the protocol


> BTW, Shariq is implementing externalizing the siging and encryption part
> [1]. Private key per SP would be a extended implementation of this. I am
> not sure if we need private key per inbound protocol. If needed we can
> again extend the implementation.
>

> [1] https://redmine.wso2.com/issues/2156
>
> Regards,
> Johann.
>
>
>>
>>>
>>>>> Thanks,
>>>>> Asela.
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>> Asela
>>>>>
>>>>> ATL
>>>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>>>  +358 449 228 979
>>>>>
>>>>> http://soasecurity.org/
>>>>> http://xacmlinfo.org/
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Godwin Amila Shrimal*
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: *+94772264165*
>>>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>>>> twitter: https://twitter.com/godwinamila
>>>> <http://wso2.com/signature>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>  +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [C5] Self signup feature in APIM store

[Asela Pathberiya]

On Thu, Apr 20, 2017 at 4:42 PM, Bhathiya Jayasekara 
wrote:

> Hi Asela,
>
> On Thu, Apr 20, 2017 at 3:17 PM, Asela Pathberiya  wrote:
>
>>
>> Hi Bhathiya,
>>
>> Just to clarify;  These registered users are not the actual end end users
>> & just application developers.  Do we really need to store these users in
>> KM ?  Can't they be stored in APIM user store?   If we need them in KM user
>> store, what is the exact reason ?
>>
>
> Please note that KeyManager interface and IDP interface are 2 different
> extenstions. Selfsign up goes to the IDP interface. So even when you're
> using an external KM, self signed up users will be added to the IS which is
> the IDP here.
>

Great.. thanks for clarify..  I thought IDP/KM as same...


>
> Thanks,
> Bhathiya
>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> Thanks,
>>>>
>>>> On Tue, Apr 18, 2017 at 6:37 PM, Bhathiya Jayasekara >>> > wrote:
>>>>
>>>>> Thanks for the information, Isura. I'll use that.
>>>>>
>>>>> Thanks,
>>>>> Bhathiya
>>>>>
>>>>> On Tue, Apr 18, 2017 at 6:33 PM, Isura Karunaratne 
>>>>> wrote:
>>>>>
>>>>>> Hi Bhathiya,
>>>>>>
>>>>>> You better to go with new REST API service [1], because it supports
>>>>>> two-step verification. That means when user self-registered, an email 
>>>>>> will
>>>>>> be sent to users email address, then user cannot login to the system 
>>>>>> until
>>>>>> confirming the email. Also, we can resend the confirmation code
>>>>>> functionality also available in new REST APIs
>>>>>>
>>>>>> Thanks
>>>>>> Isura.
>>>>>>
>>>>>> [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
>>>>>> ation/#!/operations#SelfRegister#mePost
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 18, 2017 at 2:09 AM, Bhathiya Jayasekara <
>>>>>> bhath...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In C4, APIM was using identity server's
>>>>>>> "UserRegistrationAdminService" SOAP service to register new users. But 
>>>>>>> APIM
>>>>>>> itself managed workflows related to self-signup.
>>>>>>>
>>>>>>> But since IS has workflow features now, in C5 we are planning to
>>>>>>> reuse complete user signup feature of IS in APIM too.
>>>>>>>
>>>>>>> Now we need a REST service to add/register users in IS. I was
>>>>>>> planning to use SCIM APIs for this purpose. But I got to know there is a
>>>>>>> separate REST service[1] to register users.
>>>>>>>
>>>>>>> *@IS team:* What is your recommendation here? What are the
>>>>>>> advantages we get from one over the other?
>>>>>>>
>>>>>>> Appreciate your responses.
>>>>>>>
>>>>>>> [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
>>>>>>> ation/#!/operations#SelfRegister#mePost
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --
>>>>>>> *Bhathiya Jayasekara*
>>>>>>> *Associate Technical Lead,*
>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>>>
>>>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>>> <https://twitter.com/bhathiyax>*
>>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Isura Dilhara Karunaratne*
>>>>>> Senior Software Engineer | WSO2
>>>>&

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Asela Pathberiya]

On Wed, Apr 5, 2017 at 9:04 AM, Harsha Thirimanna  wrote:

>
>
> On Apr 1, 2017 10:37 PM, "Farasath Ahamed"  wrote:
>
>
>
>
>
> On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara 
> wrote:
>
>>
>>
>> On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:
>>>

 When discussing about possible ways of implementing SSO for API Manager
 3.0 (C5) we came up with following two approaches,
 In API Manager 3.0, store, publisher and admin apps will be Oauth
 clients, which works with access tokens.

 1. Access token retrieved via SAML grant

 - When a user requests a resource, SAML client in the backend will
 create a SAML request and forwards to IDP
 - Once the user logged in to IDP,  SAML response will be sent back to
 the client.
 - SAML response will be then validated and if successful user will be
 logged into the app.
 - Exchange the SAML token to an access token


 ​

 2. Access token retrieved via Authorization code grant

 When a user requests a resource, if he is not authenticated he will be
 redirected to the Authorization server.
 Then user provides username / pwd there and will get an authorization
 code.
 Then that authorization code is used to obtain the access token and use
 that access token in subsequent calls.


 Therefore it seems that, there is no real need of using SAML here,
 and implementation wise its much simpler to use 2nd approach as there
 won't be any dependencies for SAML libraries like we had in C4.

 Appreciate your thoughts in this

>>>
>>>
>>> I am bit confused by this diagram :)
>>>
>>
>> That's fair, because this diagram is drawn not to explain all the steps
>> in OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.
>>
>>
>>>
>>> If I understood correctly, in OIDC flow diagram above the Resource
>>> Server(or rather the OAuth client) would be either Publisher, Store or
>>> Admin portal and the client is something like an agent like browser.
>>>
>>> Based on the usual OIDC flow,
>>> Then in step B, the user will be directed to IDP and upon authentication
>>> will get the authorization code(not an access token?) in step D.
>>>
>>
>> Actually all these happen in step A. Within step A, there is a call to to
>> IDP, which authenticates and fetches the auth code. Then in step B, it is
>> sent to the browser via a redirect.
>>
>> However, it doesn't look like the article in the image reference
>> discusses about OIDC. Looks like the article is about just OAuth2. (Correct
>> me if I'm missing anything here)
>>
>> Anyway, I'm +1 to have OIDC here.
>>
>
> Yeah I think it should be OIDC in any case, otherwise we can't get user
> attributes from an access token introspection call (Unless the
> Authorization Server sends custom claims) in Step E if we go by the OAuth2
> flow.
>
>
>
> Yes +1 to use second approach and it must be OIDC here.
>


Does it mean that we are removing the SAML2 SSO support from
store/publisher ?   if it is;  What is the reason for it ?

We need to support for both  SAML2 SSO & ODIC.

Thanks,
Asela.


>
>
>>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> Thereafter the resource server usually does a backend call to get the
>>> actual id_token that contain user attributes plus an access token too.
>>>
>>> Step E would be the call to userinfo endpoint with the access token get
>>> the user attributes.
>>>
>>> In the above diagram in step B the client(browser agent) receives an
>>> authorization code. Can you please explain how this happens?
>>>
>>>
>>>
 ​
 Image reference : https://www.mutuallyhuman.co
 m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/


 Thanks,
 Sajith

 --
 Sajith Kariyawasam
 *Associate Tech Lead*
 *WSO2 Inc.; http://wso2.com *
 *Committer and PMC member, Apache Stratos *
 *AMIE (SL)*
 *Mobile: 0772269575 <077%20226%209575>*

>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185 <+94%2071%20547%208185>*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> *
>>
>> ___
>> Architecture mailing l

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

[Asela Pathberiya]

On Tue, Apr 18, 2017 at 11:51 AM, Asela Pathberiya  wrote:

>
>
> On Mon, Apr 17, 2017 at 12:00 PM, Godwin Shrimal  wrote:
>
>> +1 to have separate keystores for secure vault & token signing. Any
>> reason/use case to have separate kesytores for each token signing ? Will it
>> not add more overhead on deployment and maintenance ? With the custom
>> inbound authenticator feature you can plug your own inbound authenticator
>> and then we have to think which token signing keystore we use ?
>>
>
> Usually one private key is enough for token signing.  But;  if SP/IDP
> restricts to use a privatekey which is signed by a given CA (custom CA),
>  we may need to configure more keystores..
>
>
>>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Apr 12, 2017 at 5:58 PM, Asela Pathberiya  wrote:
>>
>>> Hi All,
>>>
>>> According to the current design;   KeyStore which is defined in the
>>> carbon.xml file is used for both secure vault & token signing
>>> (SAML/id_token) which is not a good design.  We need to keep that separate
>>> keystore for secure vault as it can not be modified.
>>>
>>> Also; To add more flexibility;  it is better to have separate keystore
>>> for each token signing.  I know we can extend & achieve this,  but default
>>> implementation would be great.
>>>
>>> Shall we add this to next WSO2IS release as this is a simple improvement
>>> ?
>>>
>>
Can someone confirm whether this is in WSO2IS road map ?


>
>>> Thanks,
>>> Asela.
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>  +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>> twitter: https://twitter.com/godwinamila
>> <http://wso2.com/signature>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [C5] [APIM] Frnot End scope validation

[Asela Pathberiya]

On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray  wrote:

> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
> access to UI components such as Add, Edit, Delete buttons/links based on
> the user scopes.
>

What is reason for using scopes for authorization.. ?  Can't we use policy
based approach such as XACML ?

Thanks,
Asela.


>
> 1. We need to find scopes associate with each action (REST api call). This
> can be done in two ways.
>
>- Read the scopes from swagger definition
>
>- Associate scopes with the UI component itself.
>
> IMO associate scopes with the UI component will be more efficient than
> processing swagger definition while rendering UI.
>
> 2. We need to find logged in user scopes and persists in somewhere
>
>- We can do a introspect call and get the user scopes.
>
>- We can get the roles from logged in user claims and then find scopes
>based on role to scopes mapping
>
> In both the cases we will need to persist these info in a browser session.
> persisting user claims will be helpful for future use cases as well.
>
> We can use a secure cookie with HttpOnly and Secure flags enabled to
> persist these data.
>
>
> *Implementation*
>
> There will be a common js function that accepts UI component and then it
> validates against user scopes. Based on that the UI component will be
> enabled/ disabled.
>
> Followings are the UI components that have identified to be validated
> among currently available UIs.
>
>
> *-Publisher-*
>
> 1.Create API
> 2. API - Edit
> 3. API - Delete
> 4.Change Policies - Update
> 5. Change Labels - update
> 6. Change LC status buttons
> 7. Endpoint Update
> 8. Resource Add
> 9. Resource Save
> 10. Document Add
> 11. Document Edit/Delete
> 12. Create new version - Add
> 13. Access Controll - Not yet Available
> 14. Mediation - todo
> 15. Scripting - todo
>
> *-Store-*
> 1. Application - Add
> 2. application - View
> 3. application - Edit
> 4. application - Delete
> 5. Subscription - todo
>
> Appreciate your thoughts.
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [C5] Self signup feature in APIM store

[Asela Pathberiya]

On Wed, Apr 19, 2017 at 1:45 PM, Bhathiya Jayasekara 
wrote:

> Hi Darshana,
>
> Please find my opinions inline.
>
> On Wed, Apr 19, 2017 at 11:19 AM, Darshana Gunawardana 
> wrote:
>
>> Hi all,
>>
>> Please find few questions on the requirement and deployment below.
>>
>>1. Does APIM really need the self signup UI in the store?
>>
>> APIM Store is usually exposed to the external app developers too.
> Therefore self signup feature is required.
>
>>
>>1. Even we assume it need the self signup capability, as per the
>>above approach, store application (UI) consume self signup APIs in the
>>server. Are we expected to have this APIs on the KM server or the AM-Core
>>server?
>>
>> We will be having the service in APIM-core, and it will call IDP
> internally.
>
>>
>>1. If these APIs expected to have in the KM server, since we using a
>>proprietary APIs to register users, it would be an issue when APIM try to
>>integrate with an external KM, isn't it? What is the solution we in this
>>case?
>>
>> In APIM core, we provide an extension point (i.e. IDP interface) so that
> IDP calls can be implemented according to the IDP that is used. The default
> one will be calling IS.
>
> However, if we use SCIM to write the default implementation, external KMs
> who support SCIM won't be needing to write that again. There we have an
> advantage with SCIM over the proprietary API.
>

Hi Bhathiya,

Just to clarify;  These registered users are not the actual end end users &
just application developers.  Do we really need to store these users in KM
?  Can't they be stored in APIM user store?   If we need them in KM user
store, what is the exact reason ?

Thanks,
Asela.



>
> Thanks,
> Bhathiya
>
> Thanks,
>>
>> On Tue, Apr 18, 2017 at 6:37 PM, Bhathiya Jayasekara 
>> wrote:
>>
>>> Thanks for the information, Isura. I'll use that.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Tue, Apr 18, 2017 at 6:33 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Bhathiya,

 You better to go with new REST API service [1], because it supports
 two-step verification. That means when user self-registered, an email will
 be sent to users email address, then user cannot login to the system until
 confirming the email. Also, we can resend the confirmation code
 functionality also available in new REST APIs

 Thanks
 Isura.

 [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
 ation/#!/operations#SelfRegister#mePost



 On Tue, Apr 18, 2017 at 2:09 AM, Bhathiya Jayasekara >>> > wrote:

> Hi all,
>
> In C4, APIM was using identity server's "UserRegistrationAdminService"
> SOAP service to register new users. But APIM itself managed workflows
> related to self-signup.
>
> But since IS has workflow features now, in C5 we are planning to reuse
> complete user signup feature of IS in APIM too.
>
> Now we need a REST service to add/register users in IS. I was planning
> to use SCIM APIs for this purpose. But I got to know there is a
> separate REST service[1] to register users.
>
> *@IS team:* What is your recommendation here? What are the advantages
> we get from one over the other?
>
> Appreciate your responses.
>
> [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
> ation/#!/operations#SelfRegister#mePost
>
> Thanks,
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax
> *
> *Blog: http://movingaheadblog.blogspot.com
> *
>



 --

 *Isura Dilhara Karunaratne*
 Senior Software Engineer | WSO2
 Email: is...@wso2.com
 Mob : +94 772 254 810 <077%20225%204810>
 Blog : http://isurad.blogspot.com/




>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com *
>>>
>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> *
>>> *Twitter: https://twitter.com/bhathiyax *
>>> *Blog: http://movingaheadblog.blogspot.com
>>> *
>>>
>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <071%20856%206859>*Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/i

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

[Asela Pathberiya]

On Mon, Apr 17, 2017 at 12:00 PM, Godwin Shrimal  wrote:

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

Usually one private key is enough for token signing.  But;  if SP/IDP
restricts to use a privatekey which is signed by a given CA (custom CA),
 we may need to configure more keystores..


>
>
> Thanks
> Godwin
>
> On Wed, Apr 12, 2017 at 5:58 PM, Asela Pathberiya  wrote:
>
>> Hi All,
>>
>> According to the current design;   KeyStore which is defined in the
>> carbon.xml file is used for both secure vault & token signing
>> (SAML/id_token) which is not a good design.  We need to keep that separate
>> keystore for secure vault as it can not be modified.
>>
>> Also; To add more flexibility;  it is better to have separate keystore
>> for each token signing.  I know we can extend & achieve this,  but default
>> implementation would be great.
>>
>> Shall we add this to next WSO2IS release as this is a simple improvement ?
>>
>> Thanks,
>> Asela.
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
> twitter: https://twitter.com/godwinamila
> <http://wso2.com/signature>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

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

[Asela Pathberiya]

Hi All,

According to the current design;   KeyStore which is defined in the
carbon.xml file is used for both secure vault & token signing
(SAML/id_token) which is not a good design.  We need to keep that separate
keystore for secure vault as it can not be modified.

Also; To add more flexibility;  it is better to have separate keystore for
each token signing.  I know we can extend & achieve this,  but default
implementation would be great.

Shall we add this to next WSO2IS release as this is a simple improvement ?

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [IS] UI to define mandatory claims for JIT provisioning

[Asela Pathberiya]

On Fri, Feb 3, 2017 at 1:01 PM, Nuwandi Wickramasinghe 
wrote:

> Hi,
>
> Shall we implement $subject for next release?
>
> The requirement to define mandatory claims for JIT provisioning and prompt
> for the missing claims at the user login time was raised in [1] by Asela.
> It is possible in IS 5.3.0 with PostAuthenticationHandler extension point.
> But there's no proper place to define mandatory claims for JIT provisioning
> in UI. So in order to define mandatory claims, we will have to use service
> provider claim configuration. This is not a good approach since the Service
> Provider mandatory claims are defined to send mandatory claims to the SP
> side. It does not make sense to define other claims as mandatory there.
> Also, in this case we will have to configure these claims in every SP
> separately whenever those SPs use a particular IdP which has JIT
> provisioning configured. (Assuming there are mandatory claims for
> provisioned local profile)
>
> IMO these claims should be able to be defined from Identity Provider side
> when we enable JIT for federated authenticators. WDYT?\
>

+1  This is a basic requirement of JIT. User must be allowed to change IDP
federated claims or provide additional required claims.  Claims uris must
be configurable in IDP side.   Please try to implement this for IS 6.0.0.


>
> [1] "Identity Server 5.3.0 New Feature - Prompt for missing predefined
> user attributes in the authentication flow" architecture@
>
> thanks
> Nuwandi
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

[Architecture] What is the proper configurations for caching in WSO2IS 5.2.0/5.3.0 versions.

[Asela Pathberiya]

Hi Devs,

Default configurations of the WSO2IS 5.2.0/5.3.0 have been defined to
switch off the framework level caching.

Once you disable the caching;  when single user is authenticated
with WSO2IS using SSO,  there are around 12 INSERT queries in to database.

It is important to know the exact recommendation for WSO2IS 5.2.0/5.3.0 as
we can not found them in docs [1].

Can someone please update docs with proper recommendation ?

[1]
https://docs.wso2.com/display/IS530/Deployment+Guidelines+in+Production
https://docs.wso2.com/display/IS530/Performance+Tuning+Recommendations
https://docs.wso2.com/display/IS530/Enabling+Authentication+
Session+Persistence


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Asela Pathberiya]

On Tue, Jan 24, 2017 at 1:24 PM, Nuwandi Wickramasinghe 
wrote:

> Hi Asela,
>
> In that case you need to customize PostAuthenticationHandler
> implementation. Default implementation is found in [1].
>
> Please note that there's a bug in extension point naming reported in [2].
> Therefore when configuring the extension class, you will have give the
> extension class as an   under  in
> application-authentication.xml
>

Thanks a lot..  will give a try..


>
> [1] https://github.com/wso2/carbon-identity-framework/
> blob/master/components/authentication-framework/org.wso2.carbon.identity.
> application.authentication.framework/src/main/java/org/
> wso2/carbon/identity/application/authentication/framework/handler/request/
> impl/DefaultPostAuthenticationHandler.java
> [2] https://wso2.org/jira/browse/IDENTITY-5575
>
> best regards
> Nuwandi
>
> On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> wrote:
>>
>>> Hi Asela,
>>>
>>> This does not work in 5.3.0.
>>>
>>> IS will pop up for the mandatory claims requested by the Service
>>> Provider if they are not sent by the federated authenticator. But the
>>> claims provided by the user at this step are not persisted for federated
>>> users,  even if they are provisioned to IS. I think we have missed that
>>> part and better to persist these values in provisioned user profile.
>>>
>>> However, the mandatory claim configuration in Service Provider indicates
>>> this claim is mandatory to access that particular SP. Should we have a
>>> different configuration to define mandatory claims for provisioning ?
>>>
>>
>> Yes. it may be different..  There are required claims based on the
>> provisioning user store. Basically Mandatory claims for JIT   Can we fix
>> this for future release ?
>>
>> However;  if i want to achieve this using WSO2IS 5.3.0  what is extension
>> to customize ?  Is it JIT provisioning handler  or some other ?  (Assume
>> that i want to JIT claims which are popup/requested by SP)
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>> thanks
>>> Nuwandi
>>>
>>> On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya 
>>> wrote:
>>>
>>>> Hi Nuwandi
>>>>
>>>> Can WSO2IS popup for user claims which must be provision in to the
>>>> local user store (JIT provisioning) ?
>>>>
>>>> If federated claims are not enough to update the user store, then it is
>>>> assume that WSO2IS can popup for addition claims & persisted.. Does it work
>>>> with WSO2IS 5.3.0 ?
>>>>
>>>> Thanks,
>>>> Asela.
>>>>
>>>> On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <
>>>> nuwan...@wso2.com> wrote:
>>>>
>>>>> Sorry for the late reply. Please find the inline comments.
>>>>>
>>>>> thanks and regards.
>>>>>
>>>>> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
>>>>> jochen.traunec...@googlemail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Is the user considered as successfully authenticated even if he will
>>>>>> never provide the asked claims? What will be send back to SP if user is 
>>>>>> NOT
>>>>>> providing any claims?
>>>>>>
>>>>> No. User will not be authenticated and he will not be able access
>>>>> service provider. But the user will be asked to provide the claims only if
>>>>> they are marked as "Mandatory" in the SP configuration in Identity Server.
>>>>> You can add requested claims in SP configuration without marking them as
>>>>> mandatory. In that case IS will authenticate user and send those requested
>>>>> claims to the SP if they are available in user profile.
>>>>>
>>>>> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
>>>>>> interested in. While establishing the very first authentication session 
>>>>>> for
>>>>>> user X with SP1, that user X might be successfully authenticated but will
>>>>>> not share additional claims. Assuming some DENY response will be send 
>>>>>> back
>>>>>> to SP1 and user moves forward to SP2, will h

Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Asela Pathberiya]

On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe 
wrote:

> Hi Asela,
>
> This does not work in 5.3.0.
>
> IS will pop up for the mandatory claims requested by the Service Provider
> if they are not sent by the federated authenticator. But the claims
> provided by the user at this step are not persisted for federated users,
>  even if they are provisioned to IS. I think we have missed that part and
> better to persist these values in provisioned user profile.
>
> However, the mandatory claim configuration in Service Provider indicates
> this claim is mandatory to access that particular SP. Should we have a
> different configuration to define mandatory claims for provisioning ?
>

Yes. it may be different..  There are required claims based on the
provisioning user store. Basically Mandatory claims for JIT   Can we fix
this for future release ?

However;  if i want to achieve this using WSO2IS 5.3.0  what is extension
to customize ?  Is it JIT provisioning handler  or some other ?  (Assume
that i want to JIT claims which are popup/requested by SP)

Thanks,
Asela.


>
> thanks
> Nuwandi
>
> On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya  wrote:
>
>> Hi Nuwandi
>>
>> Can WSO2IS popup for user claims which must be provision in to the local
>> user store (JIT provisioning) ?
>>
>> If federated claims are not enough to update the user store, then it is
>> assume that WSO2IS can popup for addition claims & persisted.. Does it work
>> with WSO2IS 5.3.0 ?
>>
>> Thanks,
>> Asela.
>>
>> On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> wrote:
>>
>>> Sorry for the late reply. Please find the inline comments.
>>>
>>> thanks and regards.
>>>
>>> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
>>> jochen.traunec...@googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is the user considered as successfully authenticated even if he will
>>>> never provide the asked claims? What will be send back to SP if user is NOT
>>>> providing any claims?
>>>>
>>> No. User will not be authenticated and he will not be able access
>>> service provider. But the user will be asked to provide the claims only if
>>> they are marked as "Mandatory" in the SP configuration in Identity Server.
>>> You can add requested claims in SP configuration without marking them as
>>> mandatory. In that case IS will authenticate user and send those requested
>>> claims to the SP if they are available in user profile.
>>>
>>> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
>>>> interested in. While establishing the very first authentication session for
>>>> user X with SP1, that user X might be successfully authenticated but will
>>>> not share additional claims. Assuming some DENY response will be send back
>>>> to SP1 and user moves forward to SP2, will he then be considered as already
>>>> successfully authenticated ?
>>>>
>>> As per the current implementation, if SP1 configuration has any
>>> mandatory claims, user will not be authenticated until he provides them.
>>> User will have to login in to SP2
>>>
>>>>
>>>> Besides the "provide more claims" step we can expect a "confirm to
>>>> share claims with SP-X" become a requirement, too. This could get handled
>>>> in the handlePostAuthentication() method, too, but then expectation is that
>>>> although a DENY is send to SP-1 (when user doesn't want to share
>>>> information) the user is considered successfully authenticated in IdP (IS)
>>>> with e.g. SP-2 he already confirmed before 
>>>>
>>> We do not have this implemented. Basically, if SP configuration has
>>> marked any claim as mandatory, we consider that service provider cannot be
>>> used without that attribute. Therefore user needs to share that value with
>>> that particular SP
>>>
>>>>
>>>> Thanks,
>>>> Jochen
>>>>
>>>> Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
>>>> 06:19:
>>>>
>>>>> After , the use get authenticated and try to login to same sp by using
>>>>> different tab also we may have to prompt the input screen because there 
>>>>> may
>>>>> be additional claims will be added around this. So in that case even 
>>>>> though
>>>>> the sequence 

Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Asela Pathberiya]

Hi Nuwandi

Can WSO2IS popup for user claims which must be provision in to the local
user store (JIT provisioning) ?

If federated claims are not enough to update the user store, then it is
assume that WSO2IS can popup for addition claims & persisted.. Does it work
with WSO2IS 5.3.0 ?

Thanks,
Asela.

On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe 
wrote:

> Sorry for the late reply. Please find the inline comments.
>
> thanks and regards.
>
> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
> jochen.traunec...@googlemail.com> wrote:
>
>> Hi,
>>
>> Is the user considered as successfully authenticated even if he will
>> never provide the asked claims? What will be send back to SP if user is NOT
>> providing any claims?
>>
> No. User will not be authenticated and he will not be able access service
> provider. But the user will be asked to provide the claims only if they are
> marked as "Mandatory" in the SP configuration in Identity Server. You can
> add requested claims in SP configuration without marking them as mandatory.
> In that case IS will authenticate user and send those requested claims to
> the SP if they are available in user profile.
>
> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
>> interested in. While establishing the very first authentication session for
>> user X with SP1, that user X might be successfully authenticated but will
>> not share additional claims. Assuming some DENY response will be send back
>> to SP1 and user moves forward to SP2, will he then be considered as already
>> successfully authenticated ?
>>
> As per the current implementation, if SP1 configuration has any mandatory
> claims, user will not be authenticated until he provides them. User will
> have to login in to SP2
>
>>
>> Besides the "provide more claims" step we can expect a "confirm to share
>> claims with SP-X" become a requirement, too. This could get handled in the
>> handlePostAuthentication() method, too, but then expectation is that
>> although a DENY is send to SP-1 (when user doesn't want to share
>> information) the user is considered successfully authenticated in IdP (IS)
>> with e.g. SP-2 he already confirmed before 
>>
> We do not have this implemented. Basically, if SP configuration has marked
> any claim as mandatory, we consider that service provider cannot be used
> without that attribute. Therefore user needs to share that value with that
> particular SP
>
>>
>> Thanks,
>> Jochen
>>
>> Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
>> 06:19:
>>
>>> After , the use get authenticated and try to login to same sp by using
>>> different tab also we may have to prompt the input screen because there may
>>> be additional claims will be added around this. So in that case even though
>>> the sequence config is completed, do we call the
>>> *handlePostAuthentication**() *method implementation ? Because is saw
>>> there is if condition to check that competed or not within
>>> *handlePostAuthentication**() *method ?
>>>
>>> On Nov 2, 2016 12:07 AM, "Johann Nallathamby"  wrote:
>>>
>>>
>>>
>>> On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana 
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna 
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby 
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana >> > wrote:
>>>
>>> For federated users, it's ok to prompt missing attributes every time
>>> (unless they are associated and assert with a local user). I think we
>>> should display a message like [1].
>>>
>>>
>>> I don't know if the message in [1] will always be suitable, but since we
>>> can customize this message it should be fine. Because it really depends on
>>> the configurations admin has made in the IDP side also. So if
>>> configurations are correct then user can fill his profile in the federated
>>> IDP side and avoid filling attributes in IS.
>>>
>>>
>>>
>>> What happens when we try federated login that associated with local user
>>> and also assert with local user? Does that work without changing current
>>> implementation?
>>>
>>> And giving the option to associate user during the JIT provioning is an
>>> addional capability which also requested by many. We would need to done as
>>> a improvement for JIT provioning. For the perspective of this feature, if
>>> it works with manually associated (and locally asserted users), it would
>>> also work automatically associated users.
>>>
>>>
>>> So are we going to automatically associate JIT provisioned users?
>>> Otherwise each time it will request for attributes from user as I
>>> understand.
>>>
>>>
>>>
>>> [1] "You are trying login to application x, but it need following
>>> information filled in the user profile. You can fill those below and
>>> proceed with the authentication. But it's adviced to fill this information
>>> in your y-IdP profile in order to avoid this step every time you login."
>>>
>>> Thanks,
>>>
>>>

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

[Asela Pathberiya]

On Wed, Oct 19, 2016 at 12:57 PM, Ishara Karunarathna 
wrote:

> Hi Farasath,
>
> On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed 
> wrote:
>
>> We also need to consider how we are going to handle the 'NotApplicable'
>> and 'Indeterminate' responses by the XACML engine. Especially the
>> Indeterminate response that might be due to some missing attributes etc.
>>
>> AFAIK the decisions of multiple evaluated policies are currently
>> evaluated based on the combining algorithm (like Deny overrides, First
>> applicable) defined globally.
>> Shouldn't we also allow this algorithm to be decided at SP level?
>>
> This is a good point. Policy combining algorithm is a global configuration
> that effect to all the available policies.
> since we are having different policy categories in the future we may need
> to set different policy combining algorithms to
> different policy categories.
> Until we implement we may have to live with that.
>
WDYT ?
>

Yes. In SP level; we can define a policy set which contains multiple
policies & policy combining algo for that policy set...   But;  Yes. there
is a global policy combining algo which will effect for all the SP policy
set.  But; we can just filter out the requests for given SP by defining a
some specific value in target of the SP policy set (may be SP name).
Therefore;  we can avoid the effect from other SP policy set & global
policy algo (as there is only one policy set to combine)  Also;  Say;  we
need to enforce some rule for all the SPs. We can have a separate policy
set which will effect for all the SPs where global policy algo would be
useful..

Thanks,
Asela.


>
>
>
>>
>>
>>
>> Thanks,
>>
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana > > wrote:
>>
>>> Hi All,
>>>
>>> As per the current implementation of the Identity Server's
>>> authentication framework, it does not provide any OOTB authorization
>>> mechanism for the service providers. We are going to provide this
>>> capability to Identity server so that the users can be authorized to
>>> service providers using rules based on user attributes, userstore, time of
>>> the day, etc.
>>>
>>> Following is the proposed sequence for the implementation.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The existing authentication flow is kept as is until the authentication
>>> steps are completed and authentication result decided. At the
>>> AuthenticationRequestHandler (after authentication) if the authentication
>>> is success, we will be calling an AuthorizationHandler with the
>>> authentication context. AuthenticationHandler is responsible for evaluating
>>> the configured policies and responding back whether the user is authorized
>>> or not. If the authorization is not required or handled by the SP
>>> itself, we'll be providing the capability of bypassing the authorization
>>> step per service provider .
>>>
>>> The default implementation of the AuthorizationHandler will be using the
>>> IS's XACML engine for authorization. It will send a XACML request to the
>>> PDP and the request will be evaluated against the policies published to the
>>> PDP. Admins can write XACML policies and publish them to allow/deny the
>>> users logging into SPs based on those policies.
>>>
>>> Also, to retrieve the basic authentication context values (such as SP
>>> Name, authenticated user's username/userstore/tenant) we will provide a
>>> default PIP. In case any complex or derived attributes are needed we can
>>> retrieve them by writing a custom PIP and use them in the policies.
>>>
>>> Please share your thoughts and suggestions.
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: http://blog.pulasthi.org
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791
>
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] Grouping Identity server configurations.

[Asela Pathberiya]

On Sun, Oct 16, 2016 at 11:37 AM, Ishara Karunarathna 
wrote:

> Hi All,
>
> With the current IS implementation We have individual SP configurations
> and we associate authentication chains, claim, provisioning configurations
> etc.. to that service provider configuration.
> As a improvement to this we can group these configurations lets say a
> security circle.
>

+1


>
> For a security circle [SC].
> We can configure set of service providers within a SC.
> Associate Userstores to that SC
> Define Authentication chain, Provision config etc..
> Configre Administration policies Ex: only users in wso2admin can manage
> the wso2 security circle.
>

Are we using XACML?  May be Administration/Delegation profile...


> Group authorization policies belong to this circle.
> Once we configure those it will be applicable to all service providers and
> can override with SP level configurations.
>
We can have different login sessions to each circle.
>

So;  end user will have different session for each SC in same browser ?

Is SC  an internal detail or expose to end users (I meant whether it is
like tenant domain)?

Does request contain some detail/param on SC?

Thanks,
Asela.


>
> How can we use this.
> Achieve Enterprise SaaS application use case discussed in [1]
> No need to configure same configurations in each SP level can inherit from
> SC configurations.
> Since we are going with container base Multi tenancy in C5, If a user does
> not like, that can be handle with this security circle.
>

> Thanks,
> Ishara
> [1] "[C5 IS] Multi-tenancy in C5 based IS"
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

[Architecture] Supporting OpenID-Connect with different OAuth2 grant types.

[Asela Pathberiya]

Hi Prabath/Johann/IS Team,

According to the openid-connect specification, It is stated that the
recommended approach for granting id_token is, by using code and
implicit grant types.  But WSO2IS supports for password grant type as
well... I think it would be fine [1].  But, what are commendation for
selecting a grant types  Is there any special reason for
implementing password grant type for openid-connect  Are we
recommending the password grant type for openid-connect ... What are
the security consideration with it ?

I just doubt that we may have mistakenly supported the password grant
type for openid-connect..  Because..  it seems to be we can retrieve
an id_token even for client credential grant type which seems to be
not correct..[2] ?

[1]  
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130128/002981.html
[2] https://wso2.org/jira/browse/IDENTITY-3055

Thanks,
Asela.
-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Supporting OpenId-Connect Session Management

[Asela Pathberiya]

Hi Prabath/Johann,

It seems to be that we are supporting only the openid connect core
specification.  Is there any idea to support other profiles such as
session management [1] ?  If we are supporting this [1] profile..  I
hope that we can easily implement end to end web SSO with OpenID
connect with out using SAML?  Also.I think, It would be easy to
support this [1] profile in Identity Server. I am sorry... I can not
find any OpenId connect profiles in Identity Server road map except
the core. It seems to be that most of the other Identity Providers are
supporting them.  Any idea to add this in to Identity Server's road
map soon?

[1] http://openid.net/specs/openid-connect-session-1_0.html
[2] 
http://stackoverflow.com/questions/21248519/openid-connect-will-eventually-replace-saml-as-the-dominant-protocol-for-sso

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] HTTP PATCH method implementation for SCIM end points

[Asela Pathberiya]

On Mon, Nov 10, 2014 at 5:48 PM, Gayan Gunawardana  wrote:
> Hi Asela,
>
> Code level changes are already done, planing to integrate with IS 5.1.0
> during next week.

Thanks for reply Please note, you can move the redmine ticket to
IS 5.1.0 and it is better to update it as well..

Thanks,
Asela.

>
> Thanks,
> Gayan
>
> On Mon, Nov 10, 2014 at 3:47 PM, Asela Pathberiya  wrote:
>>
>> Hi Gayan,
>>
>> Is SCIM PATCH implementation available with next Identity Server release ?
>>
>> Thanks,
>> Asela.
>>
>> On Sun, Jul 27, 2014 at 9:10 PM, Gayan Gunawardana  wrote:
>> > Hi All,
>> >
>> > Review notes
>> >
>> > Participants : Prabath, Chamath, Prasad, Thanuja, Isura, Pulasthi, Gayan
>> >
>> >
>> > 1. Move jax rs custom patch implementation to [1] with suitable test
>> > cases.
>> >
>> > 2. Since scim provider component is a jax rs web application remove
>> > duplicate codes common to all http methods (Effective for both Group end
>> > point and User end point).
>> >
>> > 3. Put comments where ever possible and provide unit tests for patch
>> > operation.
>> >
>> > Please add if I missed anything.
>> >
>> >
>> > [1] -
>> >
>> > https://github.com/wso2-dev/carbon-deployment/tree/master/components/webapp-mgt/org.wso2.carbon.cxf.ext
>> >
>> >
>> > On Thu, Jul 24, 2014 at 4:22 PM, Gayan Gunawardana 
>> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> I have completed the feature. Can we have a review tomorrow.
>> >>
>> >> Thanks,
>> >> Gayan
>> >>
>> >>
>> >> On Mon, Jul 21, 2014 at 5:41 PM, Gayan Gunawardana 
>> >> wrote:
>> >>>
>> >>> Hi Johan,
>> >>>
>> >>> According to offline chat we had, we can ignore Use-Case 03 and
>> >>> Use-Case
>> >>> 04.
>> >>>
>> >>> For Use-Case 01 I have added extra claim for primary email.
>> >>>
>> >>> For Use-Case 02 since Identity Server does not support storing
>> >>> addresses,
>> >>> I m adding the storing addresses feature and implement patch operation
>> >>> for
>> >>> addresses.
>> >>>
>> >>> Thanks,
>> >>> Gayan
>> >>>
>> >>>
>> >>> On Mon, Jul 14, 2014 at 11:28 AM, Gayan Gunawardana 
>> >>> wrote:
>> >>>>
>> >>>> Hi Ishara,
>> >>>>
>> >>>> While looking at patch operation for Users, I have encountered
>> >>>> following
>> >>>> issues.
>> >>>>
>> >>>> Use-Case 01 : changing a User's primary email
>> >>>> Issue : Currently there is no way to specify User's primary email
>> >>>> (even
>> >>>> thought we can set as "primary":true cannot retrieve)
>> >>>>
>> >>>> Use-Case 02 : changing a User's address
>> >>>> Issue : Are we supporting adding an address for a User
>> >>>>
>> >>>> Use-Case 03 : remove a User's nickname
>> >>>> Issue  : Can we send meta information in SCIM request.
>> >>>>
>> >>>> Use-Case 04 : Remove a complex Sub-Attribute and an extended schema
>> >>>> attribute
>> >>>> Issue : Can we send meta information in SCIM request.
>> >>>>
>> >>>> Can you please add your suggestion ?
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sun, Jul 13, 2014 at 11:53 PM, Ishara Karunarathna
>> >>>> 
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Johan,
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sun, Jul 13, 2014 at 4:20 AM, Johann Nallathamby
>> >>>>> 
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Hi Ishara/Darshana,
>> >>>>>>
>> >>>>>> How does this compare with the new provisioning configurations we
>> >>>>>> provide through UI in IS 5.0?
>> >>>>>>
>> >>>>>> Currently we have capab

Re: [Architecture] HTTP PATCH method implementation for SCIM end points

[Asela Pathberiya]

Hi Gayan,

Is SCIM PATCH implementation available with next Identity Server release ?

Thanks,
Asela.

On Sun, Jul 27, 2014 at 9:10 PM, Gayan Gunawardana  wrote:
> Hi All,
>
> Review notes
>
> Participants : Prabath, Chamath, Prasad, Thanuja, Isura, Pulasthi, Gayan
>
>
> 1. Move jax rs custom patch implementation to [1] with suitable test cases.
>
> 2. Since scim provider component is a jax rs web application remove
> duplicate codes common to all http methods (Effective for both Group end
> point and User end point).
>
> 3. Put comments where ever possible and provide unit tests for patch
> operation.
>
> Please add if I missed anything.
>
>
> [1] -
> https://github.com/wso2-dev/carbon-deployment/tree/master/components/webapp-mgt/org.wso2.carbon.cxf.ext
>
>
> On Thu, Jul 24, 2014 at 4:22 PM, Gayan Gunawardana  wrote:
>>
>> Hi All,
>>
>> I have completed the feature. Can we have a review tomorrow.
>>
>> Thanks,
>> Gayan
>>
>>
>> On Mon, Jul 21, 2014 at 5:41 PM, Gayan Gunawardana  wrote:
>>>
>>> Hi Johan,
>>>
>>> According to offline chat we had, we can ignore Use-Case 03 and Use-Case
>>> 04.
>>>
>>> For Use-Case 01 I have added extra claim for primary email.
>>>
>>> For Use-Case 02 since Identity Server does not support storing addresses,
>>> I m adding the storing addresses feature and implement patch operation for
>>> addresses.
>>>
>>> Thanks,
>>> Gayan
>>>
>>>
>>> On Mon, Jul 14, 2014 at 11:28 AM, Gayan Gunawardana 
>>> wrote:

 Hi Ishara,

 While looking at patch operation for Users, I have encountered following
 issues.

 Use-Case 01 : changing a User's primary email
 Issue : Currently there is no way to specify User's primary email (even
 thought we can set as "primary":true cannot retrieve)

 Use-Case 02 : changing a User's address
 Issue : Are we supporting adding an address for a User

 Use-Case 03 : remove a User's nickname
 Issue  : Can we send meta information in SCIM request.

 Use-Case 04 : Remove a complex Sub-Attribute and an extended schema
 attribute
 Issue : Can we send meta information in SCIM request.

 Can you please add your suggestion ?



 On Sun, Jul 13, 2014 at 11:53 PM, Ishara Karunarathna 
 wrote:
>
> Hi Johan,
>
>
>
> On Sun, Jul 13, 2014 at 4:20 AM, Johann Nallathamby 
> wrote:
>>
>> Hi Ishara/Darshana,
>>
>> How does this compare with the new provisioning configurations we
>> provide through UI in IS 5.0?
>>
>> Currently we have capability for service providers to configure which
>> user store they want the users/groups to be provisioned to in Service
>> Provider UI under inbound provisioning configurations. The same thing is
>> also there in the Resident Service Provider configurations. In both 
>> places
>> we can skip selecting a user store which is effectively dumb mode. In 
>> that
>> case how should this work with the file based configurations?
>>
>> If we haven't thought about it my idea is,
>>
>> 1. If configuration says dumb mode then no service provider should be
>> able to provision to any user store (its a global config that needs to be
>> honoured, we might need to lock the option in the UI).
>
> Current implementation this works in this way. what we have to do is
> lock the SCIM provisioning.
>
>>
>> 2. If configuration says non-dumb mode, then service providers can
>> selectively provision to user stores according to their preference (even 
>> can
>> do dumb mode by not selecting user store in inbound provisioning UI).
>
> In this case if no user store is selected, users can be provisioned to
> any user store, if its selected users will be provisioned only to that 
> user
> store .
>
> This is how it works.
> @Darshana Please add if something missing.
>
> Thanks,
> -Ishara
>>
>>
>> Thoughts?
>>
>> Thanks,
>> Johann.
>>
>>
>> On Fri, Jul 11, 2014 at 6:58 PM, Ishara Karunarathna
>>  wrote:
>>>
>>> Hi Gayan,
>>>
>>>
>>> On Fri, Jul 11, 2014 at 1:15 AM, Gayan Gunawardana 
>>> wrote:

 Hi Ishara,

 Could you please elaborate more about dump mode in SCIMUserManager
 and how the changes should be reflected to dump mode.
>>>
>>> In dumb mode IS which is configured in dumb mode will act as a
>>> provisioning hub only. It wont store Users or Roles in its user store.
>>> It will re provision these resources to configures SCIM service
>>> providers.
>>>
>>> You will configure this in provisioning-config.xml configuration
>>> file.
>>> [IS_Home]/repository/conf/
>>>
>>> Thanks,
>>> -Ishara
>>>

 Thanks,
 Gayan


 On Thu, Jul 10, 2014 at 9:20 AM, Gayan Gunawardana 
 wrote:
>

Re: [Architecture] Load Balancing WSO2 Admin Services

[Asela Pathberiya]

On Wed, Mar 5, 2014 at 3:10 PM, Sameera Jayasoma  wrote:
> Hi Asela,
>
>
> On Wed, Mar 5, 2014 at 10:55 AM, Asela Pathberiya  wrote:
>>
>> Hi All,
>>
>> In some Identity Server deployment, there are clients (web
>> applications, Application clients and so on) that talk to admin
>> services in Identity server such as user management, entitlement  and
>> s on... To access these admin services, client must be authenticated
>> to Identity Server. We can configure some pre-defined user for the
>> client application and client would always be authenticated to admin
>> service using the defined user. It is not good to authenticate for
>> every requests and populate the contexts, therefore normally
>> authenticated session info (Cookie) would be used by the clients.
>>
>> If we want to achieve high availability and load distribution, you
>> need to load balance the clients requests with clustered Identity
>> server instances. As WSO2 Identity Server (and all WSO2 products) does
>> not support for user session replication across cluster nodes.
>> Therefore we may need to use sticky session with the load balancer..
>> But  If LB only considers the sticky session as the only metric for
>> load balancing,  All request would be received to an one node of the
>> cluster.. There would not be any use from other nodes..(no
>> Active-Active nodes)
>
>
> No. All requests will not directed to a single server even we use sticky
> sessions. Only the requests related to a single session will get routed to
> the same server. Requests belongs a different session will get routed a
> different server in the cluster.
>
> This is how we've been clustering our products with management consoles.
> With sticky sessions you will get true load balancing.

Yes..  that is the normal scenario..  As i have mentioned above, There
is only one pre-defined  user who is authenticated with the admin
server.
To be clear, please take following examples.

1. OAuth or Entitlement mediator  calls to WSO2IS. --> When we
configure these mediators, we configure user/password within the
mediator. Those user/pass are used to authenticate for every request.
Then If, we configure a LB(with sticky session) between ESB and
IS,  LB can not do the load distribution  (No Active-Active)

2. API Gateway calls to Key manager -->   AFAIK, API Gateway calls the
admin service of the key manager.  User/Pass has been configure in the
api-manager.xml file. Therefore Gateway always uses same user/pass.
Then if we configure a LB(with sticky session) between API Gateway
and Key manager ,  LB can not do the load distribution(No
Active-Active)


Thanks,
Asela.

>
> Thanks,
> Sameera.
>>
>>
>> Can typical LB (WSO2 ELB,  Apache HTTPD) take other metrics for load
>> balancing when sticky session has been configured? Are they
>> intelligent enough ?
>> As I know, user session replications would be supported with Carbon
>> 5..  Till what is the best solution for load balancing the Admin
>> services?  I have written some blog about this [1].. which may be
>> helpful.  what is in the blog, may not be the best approaches..
>>
>> [1] http://soasecurity.org/2014/03/04/load-balancing-wso2-admin-services/
>>
>> Thanks,
>> Asela.
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933
>
>
>
>
> --
> Sameera Jayasoma,
> Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://sameera.adahas.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Load Balancing WSO2 Admin Services

[Asela Pathberiya]

Hi All,

In some Identity Server deployment, there are clients (web
applications, Application clients and so on) that talk to admin
services in Identity server such as user management, entitlement  and
s on... To access these admin services, client must be authenticated
to Identity Server. We can configure some pre-defined user for the
client application and client would always be authenticated to admin
service using the defined user. It is not good to authenticate for
every requests and populate the contexts, therefore normally
authenticated session info (Cookie) would be used by the clients.

If we want to achieve high availability and load distribution, you
need to load balance the clients requests with clustered Identity
server instances. As WSO2 Identity Server (and all WSO2 products) does
not support for user session replication across cluster nodes.
Therefore we may need to use sticky session with the load balancer..
But  If LB only considers the sticky session as the only metric for
load balancing,  All request would be received to an one node of the
cluster.. There would not be any use from other nodes..(no
Active-Active nodes)

Can typical LB (WSO2 ELB,  Apache HTTPD) take other metrics for load
balancing when sticky session has been configured? Are they
intelligent enough ?
As I know, user session replications would be supported with Carbon
5..  Till what is the best solution for load balancing the Admin
services?  I have written some blog about this [1].. which may be
helpful.  what is in the blog, may not be the best approaches..

[1] http://soasecurity.org/2014/03/04/load-balancing-wso2-admin-services/

Thanks,
Asela.



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Provide support for self signup for tenants' APIStores

[Asela Pathberiya]

On Wed, Jan 22, 2014 at 4:51 PM, Lalaji Sureshika  wrote:

> Hi,
>
> I checked the code and found below configuration need to be added to
> identity.xml,in-order to configure the self signup user's assigning role.
>
> 
> 
> test
> true
> 
> 
>
> Addition to configuring custom roles for self registration function,is
> there a config element to enable/disable  self signup functionality? As I
> found there's no such config.It's based on the users-store read-only
> mode/not.
> I'm asking this because, ,in api-manager.xml file also we are keeping a a
>  section as below.That api-manager.xml contains one additional
> attribute to enable/disable self signup functionality in running server
> ,which is not available in the config of identity.xml. If there is a
> similar config attribute in identity.xml,we can totally deprecate the use
> of  in api-manager.xml and stick only to identity.xml config..
>
> 
> true
> subscriber1
>
> 
>
> If there's no such config element available in identity.xml,shall we add
> such property to  config in identity.xml and improve the code
> of self-signup service based on it,as I feel it's a useful improvement from
> IS side as well.. Appreciate thoughts on this..
>

+1. It is better to have a property to enable/disable in the identity.xml.
  I  o not think we can configure multiple roles (multiple SignUpRole
elements) ,  If not, we can fix it as well

Thanks.
Asela.


>
> Thanks;
>
>
>
>
>
> On Wed, Jan 22, 2014 at 2:30 PM, Lalaji Sureshika  wrote:
>
>> Hi,
>>
>> On Wed, Jan 22, 2014 at 2:04 PM, Prabath Siriwardena wrote:
>>
>>> I think the right approach is to use [1]. UserSelfRegistrationService
>>> will add users to the Identity role by default. But, if you want to add the
>>> user to the subscriber role, you can make it configurable.
>>>
>> Thanks for pointing it. Wasn't aware that the default role for add users
>> from  "UserSelfRegistrationService" service is configurable.Will follow
>> this approach without using a separate listener class.
>>
>> Thanks;
>>
>>>
>>> Also - with UserSelfRegistrationService - you can specify to which user
>>> stores you need to add users.
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Wed, Jan 22, 2014 at 11:22 AM, Lalaji Sureshika wrote:
>>>
 Hi,

 With current WSO2 APIStore self signup functionality,we do support only
 for super tenant APIStore. We are planning to extend it to support for
 tenant users as well.

 With current signup approach, we do two web service calls as;
 1) call  "UserSelfRegistrationService" to add the user
 2) call  "UserAdmin" to assign the subscriber role to the user

 With above approach,for the 2) call,we need to authenticate and thus
 need to have admin credentials predefined.But in tenant mode,to do above 2)
 we cannot keep tenant admin credentials predefined in a config file and 
 use.

 Thus without doing above 2) web service call,we are going to achieve
 the role assignment from writing a custom user store listener
 implementation and do the role-assignment as a PreAddUser operation.This
 way,it'll not required to keep tenant admin/super admin credentials and
 will only do one web service call for signup.

 Appreciate your feedback on this.



 Thanks;

 --
 Lalaji Sureshika
 WSO2, Inc.;  http://wso2.com/
 email: lal...@wso2.com;
 blog: http://lalajisureshika.blogspot.com



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


>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Twitter : @prabath
>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>
>>> Mobile : +94 71 809 6732
>>>
>>> http://blog.facilelogin.com
>>> http://blog.api-security.org
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Lalaji Sureshika
>> WSO2, Inc.;  http://wso2.com/
>> email: lal...@wso2.com; cell: +94 71 608 6811
>> blog: http://lalajisureshika.blogspot.com
>>
>>
>>
>
>
> --
> Lalaji Sureshika
> WSO2, Inc.;  http://wso2.com/
> email: lal...@wso2.com; cell: +94 71 608 6811
> blog: http://lalajisureshika.blogspot.com
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Improving performance of Balana

[Asela Pathberiya]

Hi All,

As It is discussed; There are two easy ways that could improve the
performance of Balana.

1. Parallel evaluation of XACML policies.

In Balana, 1st, It would be check whether each policies is valid according
to the target element And then it starts the evaluating of matched
policies..  It is great, if we can do this parallel Or also there may some
other points to improve this.

2. Use thread local variables to store attribute values as suggested by
Stefano [1]. Related jira [2]

Any volunteer to work on this?

[1]
http://stackoverflow.com/questions/20401808/wso2-identity-server-improve-the-performance-of-an-attributefindermodule-for-at/
[2] https://wso2.org/jira/browse/COMMONS-104

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Customizing OAuth access token value by an extension

[Asela Pathberiya]

On Tue, Dec 17, 2013 at 1:23 PM, Prabath Siriwardena wrote:

> +1
>
> Please create an issue in Redmine..
>

Done... And OT jira is created.  Johann, actually this was also in
stackoverflow [1]

[1]
http://stackoverflow.com/questions/20374120/custom-oauth2-token-after-a-sam2-assertion-check

Thanks,
Asela.

>
> Thanks & regards,
> -Prabath
>
>
> On Tue, Dec 17, 2013 at 12:29 PM, Asela Pathberiya  wrote:
>
>> Hi All,
>>
>> AFAIK,  OAuth token value can be an any string and there is no special
>> format has been defined. Therefore I guess, It is better to create an
>> extension to build the access token. Currently, It seems to be that OAuth
>> implementation have not an simple extension to customize the returning
>> access token value. But i have seen in the implementation itself,  access
>> token is customized by appending user names in to it, by depending on the
>> parameters in the configuration. Like that, in the future there may be
>> scenario, where we want to customize the value.  Is it good to provide such
>> extension? wdyt?
>>
>> Thanks,
>> Asela.
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://blog.api-security.org
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Customizing OAuth access token value by an extension

[Asela Pathberiya]

Hi All,

AFAIK,  OAuth token value can be an any string and there is no special
format has been defined. Therefore I guess, It is better to create an
extension to build the access token. Currently, It seems to be that OAuth
implementation have not an simple extension to customize the returning
access token value. But i have seen in the implementation itself,  access
token is customized by appending user names in to it, by depending on the
parameters in the configuration. Like that, in the future there may be
scenario, where we want to customize the value.  Is it good to provide such
extension? wdyt?

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access tokens are differ based on the scope?

[Asela Pathberiya]

On Thu, Dec 5, 2013 at 3:07 PM, Ishara Karunarathna wrote:

> Hi All,
>
> This is already fixed in 4.2.1 trunk, and will add this to IS 4.6.0
> release.
>

Great...!!!

Thanks,
Asela.


>
> Thanks,
> Ishara.
>
>
> On Thu, Dec 5, 2013 at 2:51 PM, Asela Pathberiya  wrote:
>
>> Hi Ishara,
>>
>> I guess,  you did some fix on this. Is this fix already in next release?
>>
>> Thanks,
>> Asela.
>>
>>
>>  On Fri, Oct 25, 2013 at 4:34 PM, Prabath Siriwardena 
>> wrote:
>>
>>> Yes.. We cannot give the same access token for different scopes.
>>>
>>> +1 for fixing this.
>>>
>>> Thanks...
>>>
>>> Sent from my mobile device
>>>
>>> > On Oct 25, 2013, at 5:29 PM, Asela Pathberiya  wrote:
>>> >
>>> > Hi All,
>>> >
>>> > AFAIK,  currently OAuth2 token endpoint returns the same access token
>>> for different scope. Access tokens are issued per client and resource
>>> owner. I guess, it must be per client, resource owner and scope.  If we are
>>> implementing scope validation  and resource owner authorization, i guess,
>>> it is better to support this. Can we support this for next release of
>>> Identity Server, if this is not yet done.?
>>> >
>>> > Thanks,
>>> > Asela.
>>> >
>>> > --
>>> > Thanks & Regards,
>>> > Asela
>>> >
>>> > ATL
>>> > Mobile : +94 777 625 933
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933
>>
>
>
>
> --
> Ishara Karunarathna
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile: +94
> 718211678
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access tokens are differ based on the scope?

[Asela Pathberiya]

Hi Ishara,

I guess,  you did some fix on this. Is this fix already in next release?

Thanks,
Asela.


On Fri, Oct 25, 2013 at 4:34 PM, Prabath Siriwardena wrote:

> Yes.. We cannot give the same access token for different scopes.
>
> +1 for fixing this.
>
> Thanks...
>
> Sent from my mobile device
>
> > On Oct 25, 2013, at 5:29 PM, Asela Pathberiya  wrote:
> >
> > Hi All,
> >
> > AFAIK,  currently OAuth2 token endpoint returns the same access token
> for different scope. Access tokens are issued per client and resource
> owner. I guess, it must be per client, resource owner and scope.  If we are
> implementing scope validation  and resource owner authorization, i guess,
> it is better to support this. Can we support this for next release of
> Identity Server, if this is not yet done.?
> >
> > Thanks,
> > Asela.
> >
> > --
> > Thanks & Regards,
> > Asela
> >
> > ATL
> > Mobile : +94 777 625 933
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Issuing JWT token for client_credential grant type

[Asela Pathberiya]

On Fri, Nov 29, 2013 at 10:53 AM, Asela Pathberiya  wrote:

> Hi Prabath/Johann,
>
> Thanks for reply.
>
>
> On Fri, Nov 29, 2013 at 10:40 AM, Prabath Siriwardena wrote:
>
>> If its the client credentials - the resource owner (end user) is the
>> client it self.
>>
>
> Yes..  then client would be the resource owner. Then authorized user would
> be the client. I guess, Server identify it by the login user when the
> client registration is done or  there is an method to "setUserName"
>

Got this working by fixing jira [1].  It seems that user name is not added
properly with "setUserName()" when registering an application. If the
intention of this user name property is different, Please let me know.
Thanks a lot.

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

Thanks,
Asela.


>
>
>> JWT is independent from OAuth - and its implementation in API - M is
>> specific to WSO2.
>>
>
> Got it
>
>
> Thanks,
> Asela.
>
>
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Fri, Nov 29, 2013 at 10:16 AM, Asela Pathberiya wrote:
>>
>>> Hi All,
>>>
>>> Our current OAuth implementation issues JWT token when validating an
>>> OAuth token that is granted by client credential grant type. This JWT token
>>> contains end user name and user's attributes. Please refer jira [1].
>>>
>>> 1. How we are identifying the authorized user and claims in the JWT
>>> token when client credential grant type is used?
>>>
>>> 2. Can we find any thing related to this in the OAuth specification? If,
>>> Please point me. I could not still find.
>>>
>>> IMO, It seems to be that It could not be returned end user and user's
>>> attribute with this grant type. Please correct me, if wrong.
>>>
>>> [1] https://wso2.org/jira/browse/APIMANAGER-1329
>>>
>>> Thanks,
>>> Asela.
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://blog.api-security.org
>>
>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Revoking client secret on OAuth

[Asela Pathberiya]

On Fri, Nov 29, 2013 at 12:19 PM, Prabath Siriwardena wrote:

>
> On Fri, Nov 29, 2013 at 11:14 AM, Johann Nallathamby wrote:
>
>> Hi Asela,
>>
>> I think deleting the application and creating it again is fine. Its not a
>> common case so its fine to re do the authorization.
>>
>
> No.. its not acceptable to delete and redo. This will make all previously
> collected data/stats unusable. We need to have a functionality to
> regenerate the key.
>


+1   Following is got this from the spec.  We only want to invalidate
code and refresh token, not others...

"An authorization server may revoke a client’s secret in order to prevent
abuse of a revealed secret.

Note: This measure will immediately invalidate any authorization code or
refresh token issued to the respective client."

I  guess, It is better to implement this for IS.. Jira is created to
tract [1]

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

Thanks,
Asela.





>
> Thanks & regards,
> -Prabath
>
>
>>
>>
>> On Fri, Nov 29, 2013 at 10:49 AM, Asela Pathberiya wrote:
>>
>>> Hi All,
>>>
>>> How can we revoke or update client credentials?  If there is a trusted
>>> client and when client's secret is compromised. Client would need to update
>>> this secret. (or generate new one and revoke older one). Sorry, I could not
>>> find any API method for this with IS 450.  Or else,  we need  to delete the
>>> current registration and add new client registration (Then we may need to
>>> redo the authorization grant again for end users). What would be the
>>> recommended approach?
>>>
>>> Thanks,
>>> Asela.
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Software Engineer
>> Integration Technologies Team
>>  WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://blog.api-security.org
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Issuing JWT token for client_credential grant type

[Asela Pathberiya]

Hi Prabath/Johann,

Thanks for reply.


On Fri, Nov 29, 2013 at 10:40 AM, Prabath Siriwardena wrote:

> If its the client credentials - the resource owner (end user) is the
> client it self.
>

Yes..  then client would be the resource owner. Then authorized user would
be the client. I guess, Server identify it by the login user when the
client registration is done or  there is an method to "setUserName"


> JWT is independent from OAuth - and its implementation in API - M is
> specific to WSO2.
>

Got it


Thanks,
Asela.


>
> Thanks & regards,
> -Prabath
>
>
> On Fri, Nov 29, 2013 at 10:16 AM, Asela Pathberiya  wrote:
>
>> Hi All,
>>
>> Our current OAuth implementation issues JWT token when validating an
>> OAuth token that is granted by client credential grant type. This JWT token
>> contains end user name and user's attributes. Please refer jira [1].
>>
>> 1. How we are identifying the authorized user and claims in the JWT token
>> when client credential grant type is used?
>>
>> 2. Can we find any thing related to this in the OAuth specification? If,
>> Please point me. I could not still find.
>>
>> IMO, It seems to be that It could not be returned end user and user's
>> attribute with this grant type. Please correct me, if wrong.
>>
>> [1] https://wso2.org/jira/browse/APIMANAGER-1329
>>
>> Thanks,
>> Asela.
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://blog.api-security.org
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Revoking client secret on OAuth

[Asela Pathberiya]

Hi All,

How can we revoke or update client credentials?  If there is a trusted
client and when client's secret is compromised. Client would need to update
this secret. (or generate new one and revoke older one). Sorry, I could not
find any API method for this with IS 450.  Or else,  we need  to delete the
current registration and add new client registration (Then we may need to
redo the authorization grant again for end users). What would be the
recommended approach?

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Issuing JWT token for client_credential grant type

[Asela Pathberiya]

Hi All,

Our current OAuth implementation issues JWT token when validating an OAuth
token that is granted by client credential grant type. This JWT token
contains end user name and user's attributes. Please refer jira [1].

1. How we are identifying the authorized user and claims in the JWT token
when client credential grant type is used?

2. Can we find any thing related to this in the OAuth specification? If,
Please point me. I could not still find.

IMO, It seems to be that It could not be returned end user and user's
attribute with this grant type. Please correct me, if wrong.

[1] https://wso2.org/jira/browse/APIMANAGER-1329

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Access tokens are differ based on the scope?

[Asela Pathberiya]

Hi All,

AFAIK,  currently OAuth2 token endpoint returns the same access token for
different scope. Access tokens are issued per client and resource owner. I
guess, it must be per client, resource owner and scope.  If we are
implementing scope validation  and resource owner authorization, i guess,
it is better to support this. Can we support this for next release of
Identity Server, if this is not yet done.?

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Handling SAML2 SSO Sessions

[Asela Pathberiya]

On Mon, Oct 21, 2013 at 12:34 PM, Prabath Siriwardena wrote:

> How do we handle SAML2 sessions now..?
>
> I believe we keep it in-memory..
>
> Keep this in-memory won't scale - as these sessions suppose to live long..
> and also won't be accessed frequently..
>
> Can we use an LRU cache - and persist the SAML2 sessions..?
>

> Thoughts please..
>

+1.  we need to persist it  and also it can be replicated among cluster
nodes using hazelcast caching. AFAIK older versions,  it has been
replicated using state replication mechanism in axis2. I guess, we can fix
this for next release? I could see that there are some issues, already
reported regarding this..

Thanks,
Asela.


>
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Separating 'My Identity' functionality from management console

[Asela Pathberiya]

On Tue, Sep 24, 2013 at 11:39 AM, Venura Kahawala  wrote:

> Hi,
>
> We are in the process of moving the below UI features out from the IS
> management console.
>
> 1. My Profiles
> 2. Account Recovery
> 3. My Authorized apps
> 4. OpenID
> 5. My SCIM Providers
> 6. Multifactor Authentication
> 7. Sign-up
>

8. Password change by user


>
>
> A jaggery application will be implemented with the above mentioned
> features and deployed within IS server. This application can be accessed
> via a different port. High level architecture diagram can be seen here [1].
>
> Jaggery application will be implemented ad-hearing to the caramel
> framework.
>
> [1]
> https://docs.google.com/a/wso2.com/drawings/d/1jQsKbSVnH3cHCKkNjaLqr9cBARk0pD04RLPGgid4R7M/edit?usp=sharing
>
> Please share your thoughts.
>

+1 for having this without OSGI...  It is better to use web services as you
have mentioned.

Also, is there any special reason for using Jaggery?  Because , i see that
web app that you are developing would not be much portable. Actually in a
practical situation, i may have already developed web application that is
running on an app server. Then i need to enable some identity management
features (account recovery, change password, signup) in to my exiting web
app. Therefore i would add presentation pages for this using exiting
presentation layer. So i would look for some client side library to call
these web service APIs of Identity Server (I would not look for already
developed Jaggery app).  I guess,  it is to better to have some kind of
client side sample library where we could use to develop my presentation
pages. If we can write this Jaggery web application using kind of client
side APIs, that would be fine.  If not, I do not think there is much worth
of this for the developers who are using Identity Server's APIs.  However
it would just add some nice UI pages to WSO2 Identity Server. (when it is
developed in cloud)

Thanks,
Asela.



>
> Regards,
> Venura
>
> --
> Senior Software Engineer
>
> Mobile: +94 71 82 300 20
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture