Re: [Architecture] Dynamic backend endpoint definition for APIs in API micro gateway

[Rajith Roshan]

Hi Malintha,
On Tue, Jul 17, 2018 at 9:09 PM Malintha Amarasinghe 
wrote:

> Hi Rajith,
>
> We are using a similar method (retrieveConfig),
> https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-cli/src/main/resources/templates/httpEndpoint.mustache#L2
>
> Bdw, what is the use of instanceId in getConfigValue method? Other than
> that, those two methods are the same it seems.
>
Its the main heading of the configuration. For ex: consider the following
conf . In here the instanceId means the "JWTConfig" is the instanceID.

ex :
[JWTConfig]
   audience = "sample"
   subject = "sample"


>
> Thanks!
>
> On Tue, Jul 17, 2018 at 11:54 PM, Rajith Roshan  wrote:
>
>> Hi Malintha/Chamila
>>
>> On Thu, Jun 28, 2018 at 12:11 AM Malintha Amarasinghe 
>> wrote:
>>
>>> Hi Chamila,
>>>
>>> A small suggestion for the implementation: I think this will be
>>> relatively easier if we define a function to get a particular config from
>>> env variable name (input 1) or from the default value (input 2) (if env
>>> variable is not defined). Then we can use this function name straight in
>>> the codegen templates. I think the function can be defined in the ballerina
>>> lib sources in the gateway core so that can be reused easily.
>>>
>>
>> We already has the function in [1]. For me this feature is a simple three
>> line fix to call this function in httpEndpoint.mustache,
>> failoverEndpoin.mustache and lbEndpoint.mustache  template files :)
>>
>> Thanks!
>> Rajith
>>
>> [1] -
>> https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-core/src/main/ballerina/gateway/utils/utils.bal#L293
>>
>>
>>>
>>> Thanks!
>>>
>>> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake <
>>> chami...@wso2.com> wrote:
>>>
 Hi All,

 I'm implementing a dynamic backend endpoint feature which will provide
 users the capability to define dedicated backends for the same API.





 This feature is a bit similar to what we have in API Manager where we
 define endpoints with variables and resolve it during the runtime (say we
 set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather
 and resolve them using system variables, etc).

 Similarly, We plan to provide a method to override the backend endpoint
  uri from the API. But this method doesn't depend on whether the URL
 is defined with template structure (with {uri.var.host}, etc).

 For example, If there is an API with TestAPI and version 1.0, we could
 define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment
 variables, value in the TOML format or as command-line parameters and
 override the existing related endpoint during the startup time. If the
 properties are not provided, then we use endpoint defined in the API as the
 default endpoint.

 This way, a user can start the micro-gateway with the default backend
 endpoint or he can override it during the startup time. This will give the
 capability to call dedicated endpoints for each environment

 Chamila.

 --
 Regards,
 Chamila Adhikarinayake
 WSO2, Inc.
 Mobile - +94712346437
 Email  - chami...@wso2.com
 Blog  -  http://helpfromadhi.blogspot.com/

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


>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Rajith Roshan
>> Senior Software Engineer, WSO2 Inc.
>> Mobile: +94-717-064-214
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Methods to get currentSubject and currentStep in authentication script

[Senthalan Kanagalingam]

Hi Harshan,

No, when configuring the authentication steps, we can specify any step
as subject-identifier-step. There will be no relationship
between subject-identifier-step and last-authenticated-step.

thanks

On Mon, Jul 16, 2018 at 3:39 PM Harshan Liyanage  wrote:

> Hi Senthalan,
>
> According to your explanation, context.currentSubject will return either 
> *subject-identifier-step
> *or *last-authenticated-step. *Do we have any direct relationship between
> the *subject-identifier-step *and *last-authenticated-step? *I'm just
> asking to clarify things.
>
> Regards,
>
> Harshan Liyanage
> Mobile: *+94765672894*
> Email: hars...@wso2.com
> Blog: http://harshanliyanage.blogspot.com/
> Medium: https://medium.com/@harshan.dll
> *WSO2, Inc.:** wso2.com *
> lean.enterprise.middleware.
>
>
> On Sat, Jul 14, 2018 at 2:38 PM Senthalan Kanagalingam 
> wrote:
>
>> Hi Harshan,
>>
>> On Fri, Jul 13, 2018 at 11:26 AM Harshan Liyanage 
>> wrote:
>>
>>> Hi Senthalan,
>>>
>>> What I understood by reading your description on the behavior of the
>>> *context.currentSubject *method is that it always returns the subject
>>> of the *last-completed-subject-identifier-step* rather than the subject
>>> of the current subject identifier step. If my understanding is correct, I
>>> suggest you change it to something more meaningful name such as
>>> *context.lastSubject*.
>>>
>>
>> No, if the* subject-identifier-step *is not completed, this method will
>> return the subject of the lastly authenticated step. if 
>> *subject-identifier-step
>> *is completed, it will return the subject of the
>> *subject-identifier-step.*
>>
>> So, I think the name lastSubject can be meant as lastly authenticated
>> steps' subject.
>>
>> thanks,
>>
>>
>>>
>>> I'm +1 with *context.currentStep.*
>>>
>>> Thanks,
>>>
>>> Harshan Liyanage
>>> Mobile: *+94765672894*
>>> Email: hars...@wso2.com
>>> Blog: http://harshanliyanage.blogspot.com/
>>> Medium: https://medium.com/@harshan.dll
>>> *WSO2, Inc.:** wso2.com *
>>> lean.enterprise.middleware.
>>>
>>>
>>> On Tue, Jul 10, 2018 at 9:39 PM Senthalan Kanagalingam <
>>> sentha...@wso2.com> wrote:
>>>
 Hi all,

 I am working on to get the currently authenticated subject and
 currently executing step from the authentication script. Now, if the
 identity admin wants to get the authenticated subject, he/she has to know
 which step was set as the subject identifier step and have to call,
 "context.step[].subject".

 So, we have planned to implement a method as,

 *context.currentSubject *

 which will return the subject of the "subject identifier step", if that
 step is completed. Else return the subject of the last completed step.

 Another implementation is to have a method to get the currently exected
 method. Currently, identity admin has to specify the step number in order
 to get the details. "context.step[]". This will affect the
 reusability of the code.

 With this new implementation, the identity admin can use,

 *context.currentStep*

 which will return the executing step.

 Please share your comments on the naming of the methods.

 thanks,
 Senthalan.
 --

 *Senthalan Kanagalingam*
 *Software Engineer - WSO2 Inc.*
 *Mobile : +94 (0) 77 18 77 466*
 
 ___
 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
>>>
>>
>>
>> --
>>
>> *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*

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

Re: [Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Menaka Jayawardena]

Hi Isuru,

The certificate will be added to the nodes that are configured in
Environments in the api-manager.xml. If there is a gateway cluster, only
the manager node trust store will be updated. So we need to sync the trust
store and the sslprofiles.xml file among the other nodes in the cluster.
This should be done manually.

Thanks and Regards,
Menaka


On Wed, Jul 18, 2018 at 1:30 PM, Isuru Haththotuwa  wrote:

> Hi Menaka,
>
> In this feature, if there are a more than one Gateway nodes, how do we
> handle the trust store synchronization across those?
>
> Sorry about the extremely late question.
>
> On Wed, Jul 11, 2018 at 5:32 PM, Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>> I had an offline discussion with Sanjeewa and Malintha regarding the rest
>> API convention of using uuid instead of certificate alias.
>>
>> But, for this feature, if we adopt the UUID approach, there will be a DB
>> level modification and method signature changes. In the current approach,
>> the certificate alias is considered as the unique attribute. So, for this
>> implementation, instead of using uuid, we will be using the alias as the
>> certificate identifier.
>>
>> In the next APIM releases, necessary modifications will be done to the
>> implementation.
>>
>> Thanks and Regards,
>> Menaka
>>
>> On Tue, Jul 10, 2018 at 4:41 PM, Malintha Amarasinghe > > wrote:
>>
>>>
>>>
>>> On Tue, 10 Jul 2018, 14:40 Sanjeewa Malalgoda, 
>>> wrote:
>>>
 In our REST API design we keep using UUID to represent path to atomic
 resource. Sometimes even we had unique attribute we still used auto
 generated UUID. If we are using alias to identify resource within resource
 collection we are deviating from that convention. So i think we need to
 think about this again.
 @Malintha Amarasinghe   Thoughts?

>>>
>>> +1. Having get certificates using UUID (GET /certificates/{uuid}) is a
>>> better approach which is also consistent with other resources we already
>>> have. Similarly we can do PUT and DELETE to the same resource. To get a
>>> certificate by alias I think we can use the search functionality. (GET
>>> /certificates?alias=wso2carbon)
>>>
>>> Thanks,
>>> Malintha
>>>
>>>

 Thanks,
 sanjeewa.

 On Tue, Jul 10, 2018 at 2:24 PM Menaka Jayawardena 
 wrote:

> Hi  Mushthaq/ Fazlan,
>
> Thank you very much for the suggestions.
>
> I have used the resource path as* '/certificates/{alias}/info'*
> because it's self-explanatory. The main objective of the API (the initial
> thought) is to get the status of the certificate. (Whether it is expired 
> or
> not and the expiry date). But, we can extend this to get other basic
> information as well.
>
> So, I also think that GET *'/certificates/{alias}*' is the better
> approach.
>
> Thanks and Regards,
> Menaka
>
>
> On Tue, Jul 10, 2018 at 2:02 PM, Fazlan Nazeem 
> wrote:
>
>> Hi Menaka,
>>
>> DELETE is expecting alias in a query param and GET is expecting it to
>> be passed in a path param. I think modifying DELETE as DELETE
>> certidicates/{alias} and GET as GET certificate/{alias} is more Restful.
>>
>> On Tue, Jul 10, 2018 at 12:09 PM Menaka Jayawardena 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm working on implementing a REST API for the Dynamic Certificate
>>> Installation feature for API Manager. (User stories
>>> 
>>> )
>>>
>>> The current implementation only supports add, retrieve and delete
>>> certificate functions. For the REST API, the following additional 
>>> functions
>>> will be added.
>>>
>>> 1. Update a certificate: Users can update an uploaded certificate.
>>> 2. Get certificate information: Retrieve the basic information of a
>>> certificate. i.e expiry date, etc.
>>>
>>> I have attached the swagger definition for the APIs herewith.
>>>
>>> Any suggestions, comments are highly appreciated.
>>>
>>> Thanks and Regards,
>>> Menaka
>>>
>>> --
>>>
>>> *Menaka Jayawardena*
>>> Senior Software Engineer
>>> WSO2 Inc.
>>>
>>> Phone: +94 71 350 5470
>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>>> Blog   : https://menakamadushanka.wordpress.com/
>>>
>>>
>>
>> --
>> Thanks & Regards,
>>
>> *Fazlan Nazeem*
>> Senior Software Engineer
>> WSO2 Inc
>> Mobile : +94772338839
>> fazl...@wso2.com
>>
>
>
>
> --
>
> *Menaka Jayawardena*
> Senior Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>

 --
 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94 

Re: [Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Isuru Haththotuwa]

Hi Menaka,

In this feature, if there are a more than one Gateway nodes, how do we
handle the trust store synchronization across those?

Sorry about the extremely late question.

On Wed, Jul 11, 2018 at 5:32 PM, Menaka Jayawardena  wrote:

> Hi,
>
> I had an offline discussion with Sanjeewa and Malintha regarding the rest
> API convention of using uuid instead of certificate alias.
>
> But, for this feature, if we adopt the UUID approach, there will be a DB
> level modification and method signature changes. In the current approach,
> the certificate alias is considered as the unique attribute. So, for this
> implementation, instead of using uuid, we will be using the alias as the
> certificate identifier.
>
> In the next APIM releases, necessary modifications will be done to the
> implementation.
>
> Thanks and Regards,
> Menaka
>
> On Tue, Jul 10, 2018 at 4:41 PM, Malintha Amarasinghe 
> wrote:
>
>>
>>
>> On Tue, 10 Jul 2018, 14:40 Sanjeewa Malalgoda,  wrote:
>>
>>> In our REST API design we keep using UUID to represent path to atomic
>>> resource. Sometimes even we had unique attribute we still used auto
>>> generated UUID. If we are using alias to identify resource within resource
>>> collection we are deviating from that convention. So i think we need to
>>> think about this again.
>>> @Malintha Amarasinghe   Thoughts?
>>>
>>
>> +1. Having get certificates using UUID (GET /certificates/{uuid}) is a
>> better approach which is also consistent with other resources we already
>> have. Similarly we can do PUT and DELETE to the same resource. To get a
>> certificate by alias I think we can use the search functionality. (GET
>> /certificates?alias=wso2carbon)
>>
>> Thanks,
>> Malintha
>>
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Tue, Jul 10, 2018 at 2:24 PM Menaka Jayawardena 
>>> wrote:
>>>
 Hi  Mushthaq/ Fazlan,

 Thank you very much for the suggestions.

 I have used the resource path as* '/certificates/{alias}/info'*
 because it's self-explanatory. The main objective of the API (the initial
 thought) is to get the status of the certificate. (Whether it is expired or
 not and the expiry date). But, we can extend this to get other basic
 information as well.

 So, I also think that GET *'/certificates/{alias}*' is the better
 approach.

 Thanks and Regards,
 Menaka


 On Tue, Jul 10, 2018 at 2:02 PM, Fazlan Nazeem 
 wrote:

> Hi Menaka,
>
> DELETE is expecting alias in a query param and GET is expecting it to
> be passed in a path param. I think modifying DELETE as DELETE
> certidicates/{alias} and GET as GET certificate/{alias} is more Restful.
>
> On Tue, Jul 10, 2018 at 12:09 PM Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>> I'm working on implementing a REST API for the Dynamic Certificate
>> Installation feature for API Manager. (User stories
>> 
>> )
>>
>> The current implementation only supports add, retrieve and delete
>> certificate functions. For the REST API, the following additional 
>> functions
>> will be added.
>>
>> 1. Update a certificate: Users can update an uploaded certificate.
>> 2. Get certificate information: Retrieve the basic information of a
>> certificate. i.e expiry date, etc.
>>
>> I have attached the swagger definition for the APIs herewith.
>>
>> Any suggestions, comments are highly appreciated.
>>
>> Thanks and Regards,
>> Menaka
>>
>> --
>>
>> *Menaka Jayawardena*
>> Senior Software Engineer
>> WSO2 Inc.
>>
>> Phone: +94 71 350 5470
>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>> Blog   : https://menakamadushanka.wordpress.com/
>>
>>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>



 --

 *Menaka Jayawardena*
 Senior Software Engineer
 WSO2 Inc.

 Phone: +94 71 350 5470
 LinkedIn : https://lk.linkedin.com/in/menakajayawardena
 Blog   : https://menakamadushanka.wordpress.com/


>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94 712933253
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>
>
> --
>
> *Menaka Jayawardena*
> Senior Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* *
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] [New Feature]: Cross Protocol IDP initiated SSO flow

[Johann Nallathamby]

On Wed, Jul 18, 2018 at 12:07 PM Farasath Ahamed  wrote:

>
>
> On Wed, Jul 18, 2018 at 7:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Dinali,
>>
>> *"IdP initiated SSO"* is something we already support between WSO2 IS
>> and service providers registered in WSO2 IS.
>>
>> The names I can suggest for this feature are:
>> *1. "IdP initiated inbound federation"*
>> *2. "Federated IdP initiated SSO"*
>>
>> And I have a question on why we decided to introduce a new inbound
>> endpoint.
>>
>> From SAML PoV, redirecting from the federated IdP to the /samlsso
>> endpoint of IS with a IdP initiated SSO request and writing a request path
>> authenticator to validate the SAML or JWT assertion will also work right?
>>
>
> We do not have to write new request path authenticators. The SAML/OIDC
> federated authenticator can validate the SAML/OIDC Response if it is
> available in the initial request handled by the authenticator. So
> implicitly they will work as request path authenticators as well.
>

Understood. I think it will be good if we can do the same for other
authenticators as well. Then we can engage them in any step, and the
sequence doesn't have to be limited to one step. Anyway that's a different
conversation.

Regards,
Johann.


>
>
>>
>> And in your diagram also as the last step you are anyway initiating
>> another IdP initiated login request to the /samlsso endpoint if SAML is
>> selected in the configuration.
>>
>> So what I understand is, the intension of introducing a new endpoint is
>> to make this flow generic for any protocol right?
>>
>> That being said, OIDC doesn't anyway have an IdP initiated concept. I am
>> struggling to understanding how this would work with OIDC a service
>> provider. Would you care to explain?
>>
>> Regards,
>> Johann.
>>
>> On Tue, Jul 17, 2018 at 10:18 PM Dinali Dabarera  wrote:
>>
>>> Hi Chinthana,
>>>
>>> On Tue, Jul 17, 2018 at 10:01 PM Chintana Wilamuna 
>>> wrote:
>>>
 Hi,

 I'm assuming if there was no tenantId then we default to super tenant?

>>>
>>> ​Yes we can do that. If the response we get does not contain any tenant
>>> domain, we can consider it as carbon.super.
>>>
>>>
>>>
 Also can we make the query param of the tenantId configurable?

>>>
>>> Do you mean like, provide a configuration to add the tenant domain,
>>> similar to protocol configuration?​
>>>
>>>
 Another change on UI - since we're only supporting SAML and OIDC shall
 we make this field a drop-down instead of a text field?

>>>
>>> ​It would be nice to see some radio buttons instead of drop dows as we
>>> have only two options. WDYT ?
>>> ​
>>>
>>> Thanks!
>>> Dinali
>>>
>>>
>>> --
>>> *Dinali Rosemin Dabarera*
>>> Software Engineer
>>> WSO2 Lanka (pvt) Ltd.
>>> Web: http://wso2.com/
>>> Email : gdrdabar...@gmail.com
>>> LinkedIn 
>>> Mobile: +94770198933
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>>
>> *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*
>>
>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>

-- 

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

Re: [Architecture] [New Feature]: Cross Protocol IDP initiated SSO flow

[Farasath Ahamed]

On Wed, Jul 18, 2018 at 7:27 AM, Johann Nallathamby  wrote:

> Hi Dinali,
>
> *"IdP initiated SSO"* is something we already support between WSO2 IS and
> service providers registered in WSO2 IS.
>
> The names I can suggest for this feature are:
> *1. "IdP initiated inbound federation"*
> *2. "Federated IdP initiated SSO"*
>
> And I have a question on why we decided to introduce a new inbound
> endpoint.
>
> From SAML PoV, redirecting from the federated IdP to the /samlsso endpoint
> of IS with a IdP initiated SSO request and writing a request path
> authenticator to validate the SAML or JWT assertion will also work right?
>

We do not have to write new request path authenticators. The SAML/OIDC
federated authenticator can validate the SAML/OIDC Response if it is
available in the initial request handled by the authenticator. So
implicitly they will work as request path authenticators as well.


>
> And in your diagram also as the last step you are anyway initiating
> another IdP initiated login request to the /samlsso endpoint if SAML is
> selected in the configuration.
>
> So what I understand is, the intension of introducing a new endpoint is to
> make this flow generic for any protocol right?
>
> That being said, OIDC doesn't anyway have an IdP initiated concept. I am
> struggling to understanding how this would work with OIDC a service
> provider. Would you care to explain?
>
> Regards,
> Johann.
>
> On Tue, Jul 17, 2018 at 10:18 PM Dinali Dabarera  wrote:
>
>> Hi Chinthana,
>>
>> On Tue, Jul 17, 2018 at 10:01 PM Chintana Wilamuna 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm assuming if there was no tenantId then we default to super tenant?
>>>
>>
>> ​Yes we can do that. If the response we get does not contain any tenant
>> domain, we can consider it as carbon.super.
>>
>>
>>
>>> Also can we make the query param of the tenantId configurable?
>>>
>>
>> Do you mean like, provide a configuration to add the tenant domain,
>> similar to protocol configuration?​
>>
>>
>>> Another change on UI - since we're only supporting SAML and OIDC shall
>>> we make this field a drop-down instead of a text field?
>>>
>>
>> ​It would be nice to see some radio buttons instead of drop dows as we
>> have only two options. WDYT ?
>> ​
>>
>> Thanks!
>> Dinali
>>
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn 
>> Mobile: +94770198933
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
>
> *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*
>



-- 
Farasath Ahamed
Senior 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