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] Supporting Description and Internationalization for OAuth2 Scopes

[Hasanthi Purnima Dissanayake]

Hi Johann,

The OAuth2 scopes implementation in IS doesn't support providing a human
> readable description that can be shown in to the end-user when providing
> consent.


The OAuth2 scopes already have a description, but the internationalization
is not supported. I think this is needed for registered scopes only, not
the custom scopes

+1 for the improvement.

Thanks,
Hasanthi

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

> The OAuth2 scopes implementation in IS doesn't support providing a human
> readable description that can be shown in to the end-user when providing
> consent. Just showing the scope names doesn't help the end-user to decide
> whether to grant the scope or not.
>
> The description should also support internationalization as in challenge
> questions.
>
>
> [1] https://github.com/wso2/product-is/issues/5354
>
> 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]
>


-- 

Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
(m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Supporting Description and Internationalization for OAuth2 Scopes

[Farasath Ahamed]

On Mon, Jun 3, 2019 at 1:07 PM Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Johann,
>
> The OAuth2 scopes implementation in IS doesn't support providing a human
>> readable description that can be shown in to the end-user when providing
>> consent.
>
>
> The OAuth2 scopes already have a description, but the internationalization
> is not supported. I think this is needed for registered scopes only, not
> the custom scopes
>
What do we mean by custom scopes here?
Also does this mean all scopes need to be pre-registered at the scope
endpoint?

>
> +1 for the improvement.
>
> Thanks,
> Hasanthi
>
> On Mon, Jun 3, 2019 at 12:23 PM Johann Nallathamby 
> wrote:
>
>> The OAuth2 scopes implementation in IS doesn't support providing a human
>> readable description that can be shown in to the end-user when providing
>> consent. Just showing the scope names doesn't help the end-user to decide
>> whether to grant the scope or not.
>>
>> The description should also support internationalization as in challenge
>> questions.
>>
>>
>> [1] https://github.com/wso2/product-is/issues/5354
>>
>> 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]
>>
>
>
> --
>
> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>
>

-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 

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

Re: [Architecture] [IAM] Supporting Description and Internationalization for OAuth2 Scopes

[Hasanthi Purnima Dissanayake]

Hi Farasath,

Hi Johann,
>>
>> The OAuth2 scopes implementation in IS doesn't support providing a human
>>> readable description that can be shown in to the end-user when providing
>>> consent.
>>
>>
>> The OAuth2 scopes already have a description, but the
>> internationalization is not supported. I think this is needed for
>> registered scopes only, not the custom scopes
>>
> What do we mean by custom scopes here?
>

By default, Identity Server doesn't validate scopes. For a token request if
we provide any string as a scope a token will be issued. The scopes that
are not registered previously, but used in the token request are referred
as custom scopes.

Also does this mean all scopes need to be pre-registered at the scope
> endpoint?
>

In a production system I think scopes should be pre defined.

Thanks,
Hasanthi

On Mon, Jun 3, 2019 at 1:15 PM Farasath Ahamed  wrote:

>
>
> On Mon, Jun 3, 2019 at 1:07 PM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Johann,
>>
>> The OAuth2 scopes implementation in IS doesn't support providing a human
>>> readable description that can be shown in to the end-user when providing
>>> consent.
>>
>>
>> The OAuth2 scopes already have a description, but the
>> internationalization is not supported. I think this is needed for
>> registered scopes only, not the custom scopes
>>
> What do we mean by custom scopes here?
> Also does this mean all scopes need to be pre-registered at the scope
> endpoint?
>
>>
>> +1 for the improvement.
>>
>> Thanks,
>> Hasanthi
>>
>> On Mon, Jun 3, 2019 at 12:23 PM Johann Nallathamby 
>> wrote:
>>
>>> The OAuth2 scopes implementation in IS doesn't support providing a human
>>> readable description that can be shown in to the end-user when providing
>>> consent. Just showing the scope names doesn't help the end-user to decide
>>> whether to grant the scope or not.
>>>
>>> The description should also support internationalization as in challenge
>>> questions.
>>>
>>>
>>> [1] https://github.com/wso2/product-is/issues/5354
>>>
>>> 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]
>>>
>>
>>
>> --
>>
>> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
>> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>>
>>
>
> --
> Farasath Ahamed
> Associate Technical Lead, WSO2 Inc.: http://wso2.com
> Mobile: +94777603866
> Blog: https://farasath.blogspot.com / https://medium.com/@farasath
> Twitter: @farazath619 
> 
>
>
>
>

-- 

Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
(m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
___
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

[Johann Nallathamby]

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.

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]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Stream Processor 4.4.0 Released!

[Minudika Malshan]

*WSO2 Stream Processor 4.4.0 Released!*

WSO2 Stream Processor team is pleased to announce the release of version
4.4.0 of the WSO2 Stream Processor.

WSO2 Stream Processor is an open source embodiment of the WSO2 Analytics
platform, of which the real-time, incremental & intelligent data processing
capabilities let digital businesses create actionable business insights and
data products.

You can download this distribution from
https://wso2.com/analytics-and-stream-processing/
Online documentation is available at
https://docs.wso2.com/display/SP440/Stream+Processor+Documentation.

*How to Run1. Extract the downloaded zip.*


*2. Navigate to the /bin directory ( is the extracted
directory).*


*3. Issue one of the following commands to start the preferred runtime as
below,*


For WSO2 *Stream Processor Studio*,

   - For Windows: editor.bat
   - For Linux: ./editor.sh

For WSO2 Stream Processor *Worker* Runtime,

   - For Windows: worker.bat
   - For Linux: ./worker.sh


*For WSO2 Stream Processor Manager Runtime,*





* - For Windows: manager.bat- For Linux: ./manager.shFor WSO2 Stream
Processor Dashboard Runtime, - For Windows: dashboard.bat- For Linux:
./dashboard.sh*

*By default, the OSGi console starts with the server.New Features and
Improvements in this Release*

   - Single Sign-On feature for dashboards.
   - Health check REST API.
   - Introduced Tenant ID for WSO2 EI analytics dashboard.
   - Improvements for analytics solutions.
   - Improvements for Stream Processor Studio.
  - Extension finder feature
  - UI improvements.
  - Fault streams support in editor envrionment.
  - Fixes for connectivity issues occurred in the RDBMS store
   - Improvements and bug fixes for high available (HA) deployment feature.
   - New siddhi extensions.
  - siddhi-io-googlepubsub
  - siddhi-io-hl7
  - siddhi-io-nats
  - siddhi.io.snmp
  - siddhi.store.influxdb



*Please find the GitHub issues related to these improvements and fixes here
Known
Issues*All the open issues pertaining to WSO2 Stream Processor are reported
at the following location:
Stream Processor Issues *How You
Can ContributeMailing Lists*Join our mailing list and correspond with the
developers directly.

*Developer list: d...@wso2.org  | Subscribe | Mail Archive
*

*User forum: StackOverflow
**Reporting Issues*

*We encourage you to report issues, documentation faults, and feature
requests regarding WSO2 Stream Processor through the public Stream
Processor Git Repo .Support*We
are committed to ensuring your enterprise middleware deployment is
completely supported from evaluation to production. Our unique approach
ensures that all support leverages our open development methodology and is
provided by the very same engineers who build the technology. For more
details and to take advantage of this unique opportunity, visit
http://wso2.com/support/



*For more information about WSO2 Stream Processor, please
see https://wso2.com/analytics  or visit the
WSO2 Oxygen Tank developer portal for additional resources.Thank you for
your interest in WSO2 Stream Processor.*

*-The WSO2 Stream Processor Team-*


-- 
*Minudika Gammanpila*
Software Engineer - WSO2

Email   :  minud...@wso2.com
Mobile :  +94715659887
Web :  http://wso2.com

 
___
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 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] 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] Scope Mapping for OpenID Connect Federated Authenticator

[Johann Nallathamby]

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

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.

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


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
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

[Johann Nallathamby]

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
>
> 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 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/
>>
>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutio

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