Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

[Rasika Perera]

+1 for .

AFAIK there's no hard limitation in meta tags unless search engines cut off
at some point for the SEO.

On Wed, May 31, 2017 at 5:18 PM, Dakshika Jayathilaka 
wrote:

> Hi All,
>
> IMHO if we are going forward with meta tag we need to think about HTML
> validation as well. AFAIK according to the specification, we can't use
> value or data attrib with meta tags[1]. +1 for using content attrib.
>
> [1] https://www.w3.org/TR/html5/document-metadata.html#the-meta-element
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Associate Technical Lead
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Wed, May 31, 2017 at 4:05 PM, Jerad Rutnam  wrote:
>
>> Hi Sajith,
>>
>> As for the offline discussion we had. IMO I feel it's ok to use 
>> tag for it. But have some minor suggestions, please see the example below.
>>
>> 
>>
>> Cheers,
>>
>> On Wed, May 31, 2017 at 1:04 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of doing $subject.
>>>
>>> # What is sendToClient() function?
>>>
>>> Its a server-side JS function provided by UUF that can be used to send a
>>> server-side value to the client-side.
>>>
>>>
>>> function onGet(env) {
>>>
>>> sendToClient("contextPath", env.contextPath);
>>>
>>> }
>>>
>>>
>>> Which will produce following inline-script
>>>
>>> var contextPath="/portal";
>>>
>>>
>>> However, we are hoping to set the Content-Security-Policy header to
>>> disable inline-JS scripts as a security measure against XSS
>>> vulnerabilities (as suggested by the security team).
>>>
>>> Content-Security-Policy: upgrade-insecure-requests, *default-src 'self'*, 
>>> frame-ancestors
>>> 'none'
>>>
>>> So setting the Content-Security-Policy header to above will break the
>>> sendToClient functionality.
>>>
>>> # Proposing solution
>>>
>>> Create a  tag in the page header that contains all the values
>>> sent from server-side.
>>>
>>> 
>>>
>>>
>>>- Only one  tag will be created.
>>>- All the values sent from server-side will be composed into a JSON,
>>>and that JSON string will be encoded to Base64.
>>>- In order to access a value, webapp developer has to use the
>>>UUFClient.
>>>   - e.g. UUFClient.fromServer("contextPath") which will return
>>>   "/portal"
>>>- Please note that, this will be a breaking change for existing UUF
>>>apps/component that utilizes sendToClient() function.
>>>
>>> WDYT?
>>>
>>> Thanks.
>>> --
>>> Sajith Janaprasad Ariyarathna
>>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>>> 
>>>
>>
>>
>>
>> --
>> *Jerad Rutnam*
>> *Senior Software Engineer*
>>
>> WSO2 Inc.
>> lean | enterprise | middleware
>> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>>
>> 
>>
>
>


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

Re: [Architecture] [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

[Ayyoob Hamza]

>
>
> 1). Provide a way to map feature-permissions for the device types that are
> being created using the API.
>
we can allow this capability to be used for the pluggable device type but I
think we cannot allow to create new permissions during runtime, since this
permission hierarchy is visible to all tenants. Either we need to have a
default permission or need to stick with the existing permission during the
pluggable device type mode.

2). Implement the feature-permission mapping using the device type
> interface.
>
This is why I suggested to use it along with the feature definition. Is
this what you meant or can you please explain on which interface.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Force Delete Identity Providers

[Prabath Siriwardena]

On Wed, May 31, 2017 at 3:30 AM, Asela Pathberiya  wrote:

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

Nice :-)


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

http://facilelogin

Re: [Architecture] [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

[Malintha Fernando]

Hi Ayyoob,

+1 for the idea. In my understanding, we need to consider following two
aspects for the implementation with the new pluggable device type API.

1). Provide a way to map feature-permissions for the device types that are
being created using the API.
2). Implement the feature-permission mapping using the device type
interface.

In order to support the former, we need to send the mapping with the json
payload and perform the addition of the permission to the tree at the API
level, whereas the latter has to be performed when the device-type plugin
is picked by the server.

Please correct me if I have misunderstood anything.

Regards,
Malintha


On Tue, May 9, 2017 at 1:44 PM, Srinath Perera  wrote:

> adding Prabath.
>
> Don't we have this level of permission checks though identity components?
>
> If we have to implement this, then if we can keep the model with only
> allow actions, it will simplify the model.
>
> --Srinath
>
> On Sat, May 6, 2017 at 12:45 AM, Ayyoob Hamza  wrote:
>
>> @Sumedha,
>> Yes, it does in the context of the API. we can use the same permissions
>> in the feature. The issue is that the permission in the API does not get
>> propagated to the device context.
>>
>> @Chathura
>>
>>> What does it mean if a role R1 has access to device group G1, but
>>> doesn't have permission to any feature of devices in G1? One option is to
>>> allow such roles to only get information+status of devices.
>>>
>>> +1, we could allow the user to view the basic device info and properties.
>>
>>
>>> I think we have to maintain following mappings to support this
 permission model (most of them are currently in the DB):

 device -> device group
 feature -> permission (is this coming from the device type xml file?)

>>> permission -> role
 user -> role
 device group -> role

>>> Yes, everything except feature -> permission is currently stored in the
>> db. The changes I proposed will rely on the standard device type plugin
>> interfaces. The implementation of that interface is currently either based
>> on the file/java code but we can make this information to be stored in the
>> DB, We can do this with the changes that we are planning todo on the DAO
>> layer to add device type through the api.
>>
>>
>>>
 I think the permission evaluation model is to allow an action, if it is
 allowed by at least one path. i.e. if device D1 belongs to groups G1 and
 G2, and user U1 belongs to roles R1 and R2, if R2 is allowed to access G1,
 U1 is allowed to access D1 (although R1 is not allowed to access G2).

>>> Yes, This is how the evaluation is done in [1] but its not been used.
>>
>>
>>> We also have to decide whether we are only supporting allow action or we
 want support deny action as well (e.g. role R1 is denied from accessing
 device group G2). If we support that, we have to enforce a precedence among
 allow and deny actions. IMO not supporting deny action is ok as it will
 complicate the permission evaluation.

>>> In the current grouping implementation we only support allow action
>> capability but this implicitly tackle the deny action(e.g role R1 is not
>> assigned to group G2). In some usecases it might be more practical to have
>> only deny action rather than the allow action. But this would complicate
>> the model as you have mentioned.
>>
>> [1] https://github.com/wso2/carbon-device-mgt/blob/master/co
>> mponents/device-mgt/org.wso2.carbon.device.mgt.core/src/
>> main/java/org/wso2/carbon/device/mgt/core/authorization/Devi
>> ceAccessAuthorizationServiceImpl.java#L197
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://people.apache.org/~hemapani/
>http://srinathsview.blogspot.com/
>



-- 
*Malintha Fernando*
Software Engineer | WSO2
Mobile : +94 718874922
Blog : http://blog.malintha.org

[image: https://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

[Dakshika Jayathilaka]

Hi All,

IMHO if we are going forward with meta tag we need to think about HTML
validation as well. AFAIK according to the specification, we can't use
value or data attrib with meta tags[1]. +1 for using content attrib.

[1] https://www.w3.org/TR/html5/document-metadata.html#the-meta-element

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Wed, May 31, 2017 at 4:05 PM, Jerad Rutnam  wrote:

> Hi Sajith,
>
> As for the offline discussion we had. IMO I feel it's ok to use  tag
> for it. But have some minor suggestions, please see the example below.
>
> 
>
> Cheers,
>
> On Wed, May 31, 2017 at 1:04 PM, SajithAR Ariyarathna 
> wrote:
>
>> Hi All,
>>
>> We are in the process of doing $subject.
>>
>> # What is sendToClient() function?
>>
>> Its a server-side JS function provided by UUF that can be used to send a
>> server-side value to the client-side.
>>
>>
>> function onGet(env) {
>>
>> sendToClient("contextPath", env.contextPath);
>>
>> }
>>
>>
>> Which will produce following inline-script
>>
>> var contextPath="/portal";
>>
>>
>> However, we are hoping to set the Content-Security-Policy header to
>> disable inline-JS scripts as a security measure against XSS
>> vulnerabilities (as suggested by the security team).
>>
>> Content-Security-Policy: upgrade-insecure-requests, *default-src 'self'*, 
>> frame-ancestors
>> 'none'
>>
>> So setting the Content-Security-Policy header to above will break the
>> sendToClient functionality.
>>
>> # Proposing solution
>>
>> Create a  tag in the page header that contains all the values sent
>> from server-side.
>>
>> 
>>
>>
>>- Only one  tag will be created.
>>- All the values sent from server-side will be composed into a JSON,
>>and that JSON string will be encoded to Base64.
>>- In order to access a value, webapp developer has to use the
>>UUFClient.
>>   - e.g. UUFClient.fromServer("contextPath") which will return
>>   "/portal"
>>- Please note that, this will be a breaking change for existing UUF
>>apps/component that utilizes sendToClient() function.
>>
>> WDYT?
>>
>> Thanks.
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> 
>>
>
>
>
> --
> *Jerad Rutnam*
> *Senior Software Engineer*
>
> WSO2 Inc.
> lean | enterprise | middleware
> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>
> 
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

[SajithAR Ariyarathna]

Hi Jerad,

On Wed, May 31, 2017 at 5:12 PM, Jerad Rutnam  wrote:

> Hi Sajith,
>
> "value" attribute has a direct coupling with "name" attribute. That's why
> I thought of changing it. But in that case I would suggest to use "content"
> attribute instead, as other vendors use,
>
> e.g. 
>
+1 for "content"

Thanks.

>
>
> In other hand using "data-*" attribute in  tags is not a valid W3C
> standard. But I saw in an article it says that even though it is not valid
> as per W3C spec, still it has a meaning that it stores app data instead of
> HTML document metadata.
>
> Cheers,
>
> On Wed, May 31, 2017 at 4:50 PM, SajithAR Ariyarathna 
> wrote:
>
>> Hi Jerad,
>>
>> On Wed, May 31, 2017 at 4:05 PM, Jerad Rutnam  wrote:
>>
>>> Hi Sajith,
>>>
>>> As for the offline discussion we had. IMO I feel it's ok to use 
>>> tag for it. But have some minor suggestions, please see the example below.
>>>
>>> 
>>>
>> Based on your suggestion, I like to propose following meta tag.
>>
>> 
>>
>> IMO, using "value" instead of "data-from-server" gives a more general
>> meta tag.
>>
>>>
>>>
>> Cheers,
>>>
>>> On Wed, May 31, 2017 at 1:04 PM, SajithAR Ariyarathna >> > wrote:
>>>
 Hi All,

 We are in the process of doing $subject.

 # What is sendToClient() function?

 Its a server-side JS function provided by UUF that can be used to send
 a server-side value to the client-side.


 function onGet(env) {

 sendToClient("contextPath", env.contextPath);

 }


 Which will produce following inline-script

 var contextPath="/portal";


 However, we are hoping to set the Content-Security-Policy header to
 disable inline-JS scripts as a security measure against XSS
 vulnerabilities (as suggested by the security team).

 Content-Security-Policy: upgrade-insecure-requests, *default-src
 'self'*, frame-ancestors 'none'

 So setting the Content-Security-Policy header to above will break the
 sendToClient functionality.

 # Proposing solution

 Create a  tag in the page header that contains all the values
 sent from server-side.

 


- Only one  tag will be created.
- All the values sent from server-side will be composed into a
JSON, and that JSON string will be encoded to Base64.
- In order to access a value, webapp developer has to use the
UUFClient.
   - e.g. UUFClient.fromServer("contextPath") which will return
   "/portal"
- Please note that, this will be a breaking change for existing UUF
apps/component that utilizes sendToClient() function.

 WDYT?

 Thanks.
 --
 Sajith Janaprasad Ariyarathna
 Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
 

>>>
>>>
>>>
>>> --
>>> *Jerad Rutnam*
>>> *Senior Software Engineer*
>>>
>>> WSO2 Inc.
>>> lean | enterprise | middleware
>>> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>>>
>>> 
>>>
>>
>>
>>
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> 
>>
>
>
>
> --
> *Jerad Rutnam*
> *Senior Software Engineer*
>
> WSO2 Inc.
> lean | enterprise | middleware
> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>
> 
>



-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

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

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

[Isura Karunaratne]

Hi,

On Wed, May 31, 2017 at 1:23 PM, Asela Pathberiya  wrote:

>
>
> 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..
>
We will fix this in IS 5.4.0. Created a Jira to track [1]

Thanks
Isura.

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

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


-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810 <+94%2077%20225%204810>
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

[SajithAR Ariyarathna]

Hi Jerad,

On Wed, May 31, 2017 at 4:05 PM, Jerad Rutnam  wrote:

> Hi Sajith,
>
> As for the offline discussion we had. IMO I feel it's ok to use  tag
> for it. But have some minor suggestions, please see the example below.
>
> 
>
Based on your suggestion, I like to propose following meta tag.



IMO, using "value" instead of "data-from-server" gives a more general meta
tag.

>
>
Cheers,
>
> On Wed, May 31, 2017 at 1:04 PM, SajithAR Ariyarathna 
> wrote:
>
>> Hi All,
>>
>> We are in the process of doing $subject.
>>
>> # What is sendToClient() function?
>>
>> Its a server-side JS function provided by UUF that can be used to send a
>> server-side value to the client-side.
>>
>>
>> function onGet(env) {
>>
>> sendToClient("contextPath", env.contextPath);
>>
>> }
>>
>>
>> Which will produce following inline-script
>>
>> var contextPath="/portal";
>>
>>
>> However, we are hoping to set the Content-Security-Policy header to
>> disable inline-JS scripts as a security measure against XSS
>> vulnerabilities (as suggested by the security team).
>>
>> Content-Security-Policy: upgrade-insecure-requests, *default-src 'self'*, 
>> frame-ancestors
>> 'none'
>>
>> So setting the Content-Security-Policy header to above will break the
>> sendToClient functionality.
>>
>> # Proposing solution
>>
>> Create a  tag in the page header that contains all the values sent
>> from server-side.
>>
>> 
>>
>>
>>- Only one  tag will be created.
>>- All the values sent from server-side will be composed into a JSON,
>>and that JSON string will be encoded to Base64.
>>- In order to access a value, webapp developer has to use the
>>UUFClient.
>>   - e.g. UUFClient.fromServer("contextPath") which will return
>>   "/portal"
>>- Please note that, this will be a breaking change for existing UUF
>>apps/component that utilizes sendToClient() function.
>>
>> WDYT?
>>
>> Thanks.
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> 
>>
>
>
>
> --
> *Jerad Rutnam*
> *Senior Software Engineer*
>
> WSO2 Inc.
> lean | enterprise | middleware
> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>
> 
>



-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

___
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

[Prabath Siriwardena]

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

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

http://facilelogin.com
___
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] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

[Farasath Ahamed]

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?


> 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

[Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

[SajithAR Ariyarathna]

Hi All,

We are in the process of doing $subject.

# What is sendToClient() function?

Its a server-side JS function provided by UUF that can be used to send a
server-side value to the client-side.


function onGet(env) {

sendToClient("contextPath", env.contextPath);

}


Which will produce following inline-script

var contextPath="/portal";


However, we are hoping to set the Content-Security-Policy header to disable
inline-JS scripts as a security measure against XSS vulnerabilities (as
suggested by the security team).

Content-Security-Policy: upgrade-insecure-requests, *default-src
'self'*, frame-ancestors
'none'

So setting the Content-Security-Policy header to above will break the
sendToClient functionality.

# Proposing solution

Create a  tag in the page header that contains all the values sent
from server-side.




   - Only one  tag will be created.
   - All the values sent from server-side will be composed into a JSON, and
   that JSON string will be encoded to Base64.
   - In order to access a value, webapp developer has to use the UUFClient.
  - e.g. UUFClient.fromServer("contextPath") which will return "/portal"
   - Please note that, this will be a breaking change for existing UUF
   apps/component that utilizes sendToClient() function.

WDYT?

Thanks.
-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

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