Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Farasath Ahamed]

On Feb 15, 2017 9:50 PM, "Harsha Thirimanna"  wrote:


On Wed, Feb 15, 2017 at 10:54 PM, Ishara Karunarathna 
wrote:

>
>
> On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed 
>> wrote:
>>
>>> In the sample.yaml Service Provider configuration I noticed that we have
>>> SAML related SP configurations in two sections "requestHandlerConfigs" and
>>> "responseHandlerConfigs".
>>>
>>> Do we need this separation? Is there any advantage of decoupling request
>>> and response related configurations related to an Inbound Protocol like
>>> SAML or OAuth2?
>>>
>>>
>> ​I felt , it doesn't make sense to configure response configuration
>> within request configs.​ And there may be custom protocol that can be one
>> in request config and few  response config select based on conditions. I
>> meant, if we give this way, it would be more flexible that we give it
>> within one. WDYT ?
>>
> I will go with Farasaths suggestion, And I think it will complicate the
> common cases and would be a bad user experience. for example if some one
> configure a SAML base SP he will confused where to put what. better to be
> in a single configuration.
>

​Yes Ishara, I agree with you.  We can change it if it is confuse to do the
configuration. ​
But still we have two handlers to handle the inbound request and response
that is targeting to decouple the protocol bind. Because in standard
protocol, it is not definitely change the inbound request protocol and
response protocol. Because of that we can keep single config for both.
But when we write custom protocol to handle request response, it may be
changed the selecting of response handler based on current context
parameters and we have to let them for each and every response handlers to
keep their configs with himself and not force to get it from inbound
request handler configs.


I think it's fine for us to have this seperation in our implementation
level. But in configs we should hide this complexity as much as possible.

The most common case when some configures an inbound protocol say SAML they
expect the request and response both in the same protocol. Therefore most
natural way is to configure everything related to SAML in one place.

Therefore IMO let's make request/response handler config opaque to the end
user configuring the SP etc.


But still I agree with you to keep one config from request side to handle
both configs for request and response for standard protocol(SAML) what we
offer if you feel that it would be confused to the developers. I would like
to get others feedback also for this.

@*Prabath*, WDYT ?

>
> -Ishara
>
>>
>>
>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana >> > wrote:
>>>
 +1 for this approach in general...

 On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
 wrote:

> Hi All,
>
> Since we are moving to file base deployment for sp/idp, we have to
> create these files using yaml. While doing that we thought to resolve some
> issues and generalize the sp/idp files.
> As we have now in IS 5.3.0, we configure local authenticator in SP and
> federated authenticator in IDP file.
>

 But just to clarify the earlier behaviour in IS 5.x.x versions, no;
 it's not define local authenticator configs in SP.. rather we associate
 local authenticators to the SP.. The issue we had was, there is no way to
 configure local authenticators from the UI.. In IS 5.3.0 we provided a way
 to generate UI elements to resident IdP section, so someone need, they can
 write a new local authenticator and configure it from the resident idp..

 Basically you propose the same approach for the IS 6.0.0 with the file
 based configs..

 One improvement we can do is, rather than limiting to *idpName* and
 *authenticatorName* parameters in *authenticatorConfig*, allow it to
 pass any additional parameters to IdP (from that SP) so we won't ended up
 with the need of multiple resident idp to adequate different service
 providers requirements.


> But it doesn't make sense to specially treat to the local
> authenticator in SP side and we can consider it also as another idp.
>
 We can name it as resident-idp and SP authenticator can point the idp
> name when it want to use local one as same as it use federated one.
> We can keep other resident identity provider configuration like
> password policies, login policies, etc.. in separate config file that is
> decouple with the outbound authentication flow.
>

 What about provisioning configurations? where does that configs going
 to be in.. If the file name going to 

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Harsha Thirimanna]

On Wed, Feb 15, 2017 at 10:54 PM, Ishara Karunarathna 
wrote:

>
>
> On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed 
>> wrote:
>>
>>> In the sample.yaml Service Provider configuration I noticed that we have
>>> SAML related SP configurations in two sections "requestHandlerConfigs" and
>>> "responseHandlerConfigs".
>>>
>>> Do we need this separation? Is there any advantage of decoupling request
>>> and response related configurations related to an Inbound Protocol like
>>> SAML or OAuth2?
>>>
>>>
>> ​I felt , it doesn't make sense to configure response configuration
>> within request configs.​ And there may be custom protocol that can be one
>> in request config and few  response config select based on conditions. I
>> meant, if we give this way, it would be more flexible that we give it
>> within one. WDYT ?
>>
> I will go with Farasaths suggestion, And I think it will complicate the
> common cases and would be a bad user experience. for example if some one
> configure a SAML base SP he will confused where to put what. better to be
> in a single configuration.
>

​Yes Ishara, I agree with you.  We can change it if it is confuse to do the
configuration. ​
But still we have two handlers to handle the inbound request and response
that is targeting to decouple the protocol bind. Because in standard
protocol, it is not definitely change the inbound request protocol and
response protocol. Because of that we can keep single config for both.
But when we write custom protocol to handle request response, it may be
changed the selecting of response handler based on current context
parameters and we have to let them for each and every response handlers to
keep their configs with himself and not force to get it from inbound
request handler configs.

But still I agree with you to keep one config from request side to handle
both configs for request and response for standard protocol(SAML) what we
offer if you feel that it would be confused to the developers. I would like
to get others feedback also for this.

@*Prabath*, WDYT ?

>
> -Ishara
>
>>
>>
>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana >> > wrote:
>>>
 +1 for this approach in general...

 On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
 wrote:

> Hi All,
>
> Since we are moving to file base deployment for sp/idp, we have to
> create these files using yaml. While doing that we thought to resolve some
> issues and generalize the sp/idp files.
> As we have now in IS 5.3.0, we configure local authenticator in SP and
> federated authenticator in IDP file.
>

 But just to clarify the earlier behaviour in IS 5.x.x versions, no;
 it's not define local authenticator configs in SP.. rather we associate
 local authenticators to the SP.. The issue we had was, there is no way to
 configure local authenticators from the UI.. In IS 5.3.0 we provided a way
 to generate UI elements to resident IdP section, so someone need, they can
 write a new local authenticator and configure it from the resident idp..

 Basically you propose the same approach for the IS 6.0.0 with the file
 based configs..

 One improvement we can do is, rather than limiting to *idpName* and
 *authenticatorName* parameters in *authenticatorConfig*, allow it to
 pass any additional parameters to IdP (from that SP) so we won't ended up
 with the need of multiple resident idp to adequate different service
 providers requirements.


> But it doesn't make sense to specially treat to the local
> authenticator in SP side and we can consider it also as another idp.
>
 We can name it as resident-idp and SP authenticator can point the idp
> name when it want to use local one as same as it use federated one.
> We can keep other resident identity provider configuration like
> password policies, login policies, etc.. in separate config file that is
> decouple with the outbound authentication flow.
>

 What about provisioning configurations? where does that configs going
 to be in.. If the file name going to be *resident-idp* then all the
 configurations should be in that file when IS acting as a IdP.

 WDYT?

 Regards,
 Darshana.


> This will not effect for the existing framework implementation but
> only change the user experience that is more cleaner than now. I have
> attached the sample sp file, sample idp file and resident idp file with
> this, it would be great if i can get more feedbacks about this.
>
> thanks
>
> *Harsha Thirimanna*
> *Associate Tech

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Ishara Karunarathna]

On Thu, Feb 16, 2017 at 11:10 AM, Harsha Thirimanna 
wrote:

> Hi Ishara, thanks for the feedback,
>
> On Wed, Feb 15, 2017 at 10:49 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Harsha,
>>
>> On Thu, Feb 9, 2017 at 12:32 AM, Darshana Gunawardana 
>> wrote:
>>
>>> +1 for this approach in general...
>>>
>>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
>>> wrote:
>>>
 Hi All,

 Since we are moving to file base deployment for sp/idp, we have to
 create these files using yaml. While doing that we thought to resolve some
 issues and generalize the sp/idp files.
 As we have now in IS 5.3.0, we configure local authenticator in SP and
 federated authenticator in IDP file.

>>>
>>> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
>>> not define local authenticator configs in SP.. rather we associate local
>>> authenticators to the SP.. The issue we had was, there is no way to
>>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>>> to generate UI elements to resident IdP section, so someone need, they can
>>> write a new local authenticator and configure it from the resident idp..
>>>
>>> Are we keeping all local authenticator configurations in a single
>> resident IdP file ?
>>
>
> ​Yes we are going to define all local authenticator under resident idp
> config file that is packed  OOB. So it will not mixed up with the others. ​
>
>
>
>> In C4 base Identity servers we tread all local authentications in a same
>> level it means if we have authenticated with a Local authentication we do
>> not prompt for authentication with another authenticator.
>>
>
> ​Yes, as you mentioned, we have to concern this when we do the tooling.
> Now we have config file that can configure manually. ​
>
>
>
>> So better to consider this as well in the new framework design.
>>
>> And another question is if we configure SAML base sp using SP metadata
>> file are pointing to it through these files or populate a new file using
>> given metadata file ?
>>
>
> ​This is very valid question and we discussed this before we start this
> config file. We thought to do this import/export of SAML meta file , but
> not storing it as it is. We can allow to user to import and we convert it
> in to the our key/value model. If they export, we can dynamically build. Is
> that make sense, isn't it ?​
>
+1

-Ishara

>
>
>
>>
>> -Ishara
>>
>>> Basically you propose the same approach for the IS 6.0.0 with the file
>>> based configs..
>>>
>>> One improvement we can do is, rather than limiting to *idpName* and
>>> *authenticatorName* parameters in *authenticatorConfig*, allow it to
>>> pass any additional parameters to IdP (from that SP) so we won't ended up
>>> with the need of multiple resident idp to adequate different service
>>> providers requirements.
>>>
>>>
 But it doesn't make sense to specially treat to the local authenticator
 in SP side and we can consider it also as another idp.

>>> We can name it as resident-idp and SP authenticator can point the idp
 name when it want to use local one as same as it use federated one.
 We can keep other resident identity provider configuration like
 password policies, login policies, etc.. in separate config file that is
 decouple with the outbound authentication flow.

>>>
>>> What about provisioning configurations? where does that configs going to
>>> be in.. If the file name going to be *resident-idp* then all the
>>> configurations should be in that file when IS acting as a IdP.
>>>
>>> WDYT?
>>>
>>> Regards,
>>> Darshana.
>>>
>>>
 This will not effect for the existing framework implementation but only
 change the user experience that is more cleaner than now. I have attached
 the sample sp file, sample idp file and resident idp file with this, it
 would be great if i can get more feedbacks about this.

 thanks

 *Harsha Thirimanna*
 *Associate Tech Lead | WSO2*

 Email: hars...@wso2.com
 Mob: +94715186770 <+94%2071%20518%206770>
 Blog: http://harshathirimanna.blogspot.com/
 Twitter: http://twitter.com/harshathirimann
 Linked-In: linked-in: http://www.linkedin.com/pub/ha
 rsha-thirimanna/10/ab8/122
 

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>>
>>> *Darshana Gunawardana*Associate Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>>
>>> *E-mail: darsh...@wso2.com *
>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>>> Middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Ishara Karunarathna
>> Associate Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <+94%2071%20799%206791>
>>
>>
>>
>


-- 
Ishara Karunarathna
Associate T

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Harsha Thirimanna]

Hi Ishara, thanks for the feedback,

On Wed, Feb 15, 2017 at 10:49 PM, Ishara Karunarathna 
wrote:

> Hi Harsha,
>
> On Thu, Feb 9, 2017 at 12:32 AM, Darshana Gunawardana 
> wrote:
>
>> +1 for this approach in general...
>>
>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
>> wrote:
>>
>>> Hi All,
>>>
>>> Since we are moving to file base deployment for sp/idp, we have to
>>> create these files using yaml. While doing that we thought to resolve some
>>> issues and generalize the sp/idp files.
>>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>>> federated authenticator in IDP file.
>>>
>>
>> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
>> not define local authenticator configs in SP.. rather we associate local
>> authenticators to the SP.. The issue we had was, there is no way to
>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>> to generate UI elements to resident IdP section, so someone need, they can
>> write a new local authenticator and configure it from the resident idp..
>>
>> Are we keeping all local authenticator configurations in a single
> resident IdP file ?
>

​Yes we are going to define all local authenticator under resident idp
config file that is packed  OOB. So it will not mixed up with the others. ​



> In C4 base Identity servers we tread all local authentications in a same
> level it means if we have authenticated with a Local authentication we do
> not prompt for authentication with another authenticator.
>

​Yes, as you mentioned, we have to concern this when we do the tooling. Now
we have config file that can configure manually. ​



> So better to consider this as well in the new framework design.
>
> And another question is if we configure SAML base sp using SP metadata
> file are pointing to it through these files or populate a new file using
> given metadata file ?
>

​This is very valid question and we discussed this before we start this
config file. We thought to do this import/export of SAML meta file , but
not storing it as it is. We can allow to user to import and we convert it
in to the our key/value model. If they export, we can dynamically build. Is
that make sense, isn't it ?​



>
> -Ishara
>
>> Basically you propose the same approach for the IS 6.0.0 with the file
>> based configs..
>>
>> One improvement we can do is, rather than limiting to *idpName* and
>> *authenticatorName* parameters in *authenticatorConfig*, allow it to
>> pass any additional parameters to IdP (from that SP) so we won't ended up
>> with the need of multiple resident idp to adequate different service
>> providers requirements.
>>
>>
>>> But it doesn't make sense to specially treat to the local authenticator
>>> in SP side and we can consider it also as another idp.
>>>
>> We can name it as resident-idp and SP authenticator can point the idp
>>> name when it want to use local one as same as it use federated one.
>>> We can keep other resident identity provider configuration like password
>>> policies, login policies, etc.. in separate config file that is decouple
>>> with the outbound authentication flow.
>>>
>>
>> What about provisioning configurations? where does that configs going to
>> be in.. If the file name going to be *resident-idp* then all the
>> configurations should be in that file when IS acting as a IdP.
>>
>> WDYT?
>>
>> Regards,
>> Darshana.
>>
>>
>>> This will not effect for the existing framework implementation but only
>>> change the user experience that is more cleaner than now. I have attached
>>> the sample sp file, sample idp file and resident idp file with this, it
>>> would be great if i can get more feedbacks about this.
>>>
>>> thanks
>>>
>>> *Harsha Thirimanna*
>>> *Associate Tech Lead | WSO2*
>>>
>>> Email: hars...@wso2.com
>>> Mob: +94715186770 <+94%2071%20518%206770>
>>> Blog: http://harshathirimanna.blogspot.com/
>>> Twitter: http://twitter.com/harshathirimann
>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>>> rsha-thirimanna/10/ab8/122
>>> 
>>>
>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>> Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Ishara Karunarathna]

On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna  wrote:

>
>
> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed 
> wrote:
>
>> In the sample.yaml Service Provider configuration I noticed that we have
>> SAML related SP configurations in two sections "requestHandlerConfigs" and
>> "responseHandlerConfigs".
>>
>> Do we need this separation? Is there any advantage of decoupling request
>> and response related configurations related to an Inbound Protocol like
>> SAML or OAuth2?
>>
>>
> ​I felt , it doesn't make sense to configure response configuration within
> request configs.​ And there may be custom protocol that can be one in
> request config and few  response config select based on conditions. I
> meant, if we give this way, it would be more flexible that we give it
> within one. WDYT ?
>
I will go with Farasaths suggestion, And I think it will complicate the
common cases and would be a bad user experience. for example if some one
configure a SAML base SP he will confused where to put what. better to be
in a single configuration.

-Ishara

>
>
>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana 
>> wrote:
>>
>>> +1 for this approach in general...
>>>
>>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
>>> wrote:
>>>
 Hi All,

 Since we are moving to file base deployment for sp/idp, we have to
 create these files using yaml. While doing that we thought to resolve some
 issues and generalize the sp/idp files.
 As we have now in IS 5.3.0, we configure local authenticator in SP and
 federated authenticator in IDP file.

>>>
>>> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
>>> not define local authenticator configs in SP.. rather we associate local
>>> authenticators to the SP.. The issue we had was, there is no way to
>>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>>> to generate UI elements to resident IdP section, so someone need, they can
>>> write a new local authenticator and configure it from the resident idp..
>>>
>>> Basically you propose the same approach for the IS 6.0.0 with the file
>>> based configs..
>>>
>>> One improvement we can do is, rather than limiting to *idpName* and
>>> *authenticatorName* parameters in *authenticatorConfig*, allow it to
>>> pass any additional parameters to IdP (from that SP) so we won't ended up
>>> with the need of multiple resident idp to adequate different service
>>> providers requirements.
>>>
>>>
 But it doesn't make sense to specially treat to the local authenticator
 in SP side and we can consider it also as another idp.

>>> We can name it as resident-idp and SP authenticator can point the idp
 name when it want to use local one as same as it use federated one.
 We can keep other resident identity provider configuration like
 password policies, login policies, etc.. in separate config file that is
 decouple with the outbound authentication flow.

>>>
>>> What about provisioning configurations? where does that configs going to
>>> be in.. If the file name going to be *resident-idp* then all the
>>> configurations should be in that file when IS acting as a IdP.
>>>
>>> WDYT?
>>>
>>> Regards,
>>> Darshana.
>>>
>>>
 This will not effect for the existing framework implementation but only
 change the user experience that is more cleaner than now. I have attached
 the sample sp file, sample idp file and resident idp file with this, it
 would be great if i can get more feedbacks about this.

 thanks

 *Harsha Thirimanna*
 *Associate Tech Lead | WSO2*

 Email: hars...@wso2.com
 Mob: +94715186770 <+94%2071%20518%206770>
 Blog: http://harshathirimanna.blogspot.com/
 Twitter: http://twitter.com/harshathirimann
 Linked-In: linked-in: http://www.linkedin.com/pub/ha
 rsha-thirimanna/10/ab8/122
 

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>>
>>> *Darshana Gunawardana*Associate Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>>
>>> *E-mail: darsh...@wso2.com *
>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>>> Middleware
>>>
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Ishara Karunarathna]

Hi Harsha,

On Thu, Feb 9, 2017 at 12:32 AM, Darshana Gunawardana 
wrote:

> +1 for this approach in general...
>
> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
> wrote:
>
>> Hi All,
>>
>> Since we are moving to file base deployment for sp/idp, we have to create
>> these files using yaml. While doing that we thought to resolve some issues
>> and generalize the sp/idp files.
>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>> federated authenticator in IDP file.
>>
>
> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
> not define local authenticator configs in SP.. rather we associate local
> authenticators to the SP.. The issue we had was, there is no way to
> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
> to generate UI elements to resident IdP section, so someone need, they can
> write a new local authenticator and configure it from the resident idp..
>
> Are we keeping all local authenticator configurations in a single resident
IdP file ?
In C4 base Identity servers we tread all local authentications in a same
level it means if we have authenticated with a Local authentication we do
not prompt for authentication with another authenticator. So better to
consider this as well in the new framework design.

And another question is if we configure SAML base sp using SP metadata file
are pointing to it through these files or populate a new file using given
metadata file ?

-Ishara

> Basically you propose the same approach for the IS 6.0.0 with the file
> based configs..
>
> One improvement we can do is, rather than limiting to *idpName* and
> *authenticatorName* parameters in *authenticatorConfig*, allow it to pass
> any additional parameters to IdP (from that SP) so we won't ended up with
> the need of multiple resident idp to adequate different service providers
> requirements.
>
>
>> But it doesn't make sense to specially treat to the local authenticator
>> in SP side and we can consider it also as another idp.
>>
> We can name it as resident-idp and SP authenticator can point the idp name
>> when it want to use local one as same as it use federated one.
>> We can keep other resident identity provider configuration like password
>> policies, login policies, etc.. in separate config file that is decouple
>> with the outbound authentication flow.
>>
>
> What about provisioning configurations? where does that configs going to
> be in.. If the file name going to be *resident-idp* then all the
> configurations should be in that file when IS acting as a IdP.
>
> WDYT?
>
> Regards,
> Darshana.
>
>
>> This will not effect for the existing framework implementation but only
>> change the user experience that is more cleaner than now. I have attached
>> the sample sp file, sample idp file and resident idp file with this, it
>> would be great if i can get more feedbacks about this.
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> *Associate Tech Lead | WSO2*
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770 <+94%2071%20518%206770>
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
> Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Harsha Thirimanna]

adding Hasintha...

*Harsha Thirimanna*
*Associate Tech Lead | WSO2*

Email: hars...@wso2.com
Mob: +94715186770
Blog: http://harshathirimanna.blogspot.com/
Twitter: http://twitter.com/harshathirimann
Linked-In: linked-in:
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122


On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna  wrote:

>
>
> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed 
> wrote:
>
>> In the sample.yaml Service Provider configuration I noticed that we have
>> SAML related SP configurations in two sections "requestHandlerConfigs" and
>> "responseHandlerConfigs".
>>
>> Do we need this separation? Is there any advantage of decoupling request
>> and response related configurations related to an Inbound Protocol like
>> SAML or OAuth2?
>>
>>
> ​I felt , it doesn't make sense to configure response configuration within
> request configs.​ And there may be custom protocol that can be one in
> request config and few  response config select based on conditions. I
> meant, if we give this way, it would be more flexible that we give it
> within one. WDYT ?
>
>
>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana 
>> wrote:
>>
>>> +1 for this approach in general...
>>>
>>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
>>> wrote:
>>>
 Hi All,

 Since we are moving to file base deployment for sp/idp, we have to
 create these files using yaml. While doing that we thought to resolve some
 issues and generalize the sp/idp files.
 As we have now in IS 5.3.0, we configure local authenticator in SP and
 federated authenticator in IDP file.

>>>
>>> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
>>> not define local authenticator configs in SP.. rather we associate local
>>> authenticators to the SP.. The issue we had was, there is no way to
>>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>>> to generate UI elements to resident IdP section, so someone need, they can
>>> write a new local authenticator and configure it from the resident idp..
>>>
>>> Basically you propose the same approach for the IS 6.0.0 with the file
>>> based configs..
>>>
>>> One improvement we can do is, rather than limiting to *idpName* and
>>> *authenticatorName* parameters in *authenticatorConfig*, allow it to
>>> pass any additional parameters to IdP (from that SP) so we won't ended up
>>> with the need of multiple resident idp to adequate different service
>>> providers requirements.
>>>
>>>
 But it doesn't make sense to specially treat to the local authenticator
 in SP side and we can consider it also as another idp.

>>> We can name it as resident-idp and SP authenticator can point the idp
 name when it want to use local one as same as it use federated one.
 We can keep other resident identity provider configuration like
 password policies, login policies, etc.. in separate config file that is
 decouple with the outbound authentication flow.

>>>
>>> What about provisioning configurations? where does that configs going to
>>> be in.. If the file name going to be *resident-idp* then all the
>>> configurations should be in that file when IS acting as a IdP.
>>>
>>> WDYT?
>>>
>>> Regards,
>>> Darshana.
>>>
>>>
 This will not effect for the existing framework implementation but only
 change the user experience that is more cleaner than now. I have attached
 the sample sp file, sample idp file and resident idp file with this, it
 would be great if i can get more feedbacks about this.

 thanks

 *Harsha Thirimanna*
 *Associate Tech Lead | WSO2*

 Email: hars...@wso2.com
 Mob: +94715186770 <+94%2071%20518%206770>
 Blog: http://harshathirimanna.blogspot.com/
 Twitter: http://twitter.com/harshathirimann
 Linked-In: linked-in: http://www.linkedin.com/pub/ha
 rsha-thirimanna/10/ab8/122
 

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>>
>>> *Darshana Gunawardana*Associate Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>>
>>> *E-mail: darsh...@wso2.com *
>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>>> Middleware
>>>
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Harsha Thirimanna]

On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed  wrote:

> In the sample.yaml Service Provider configuration I noticed that we have
> SAML related SP configurations in two sections "requestHandlerConfigs" and
> "responseHandlerConfigs".
>
> Do we need this separation? Is there any advantage of decoupling request
> and response related configurations related to an Inbound Protocol like
> SAML or OAuth2?
>
>
​I felt , it doesn't make sense to configure response configuration within
request configs.​ And there may be custom protocol that can be one in
request config and few  response config select based on conditions. I
meant, if we give this way, it would be more flexible that we give it
within one. WDYT ?



>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana 
> wrote:
>
>> +1 for this approach in general...
>>
>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
>> wrote:
>>
>>> Hi All,
>>>
>>> Since we are moving to file base deployment for sp/idp, we have to
>>> create these files using yaml. While doing that we thought to resolve some
>>> issues and generalize the sp/idp files.
>>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>>> federated authenticator in IDP file.
>>>
>>
>> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
>> not define local authenticator configs in SP.. rather we associate local
>> authenticators to the SP.. The issue we had was, there is no way to
>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>> to generate UI elements to resident IdP section, so someone need, they can
>> write a new local authenticator and configure it from the resident idp..
>>
>> Basically you propose the same approach for the IS 6.0.0 with the file
>> based configs..
>>
>> One improvement we can do is, rather than limiting to *idpName* and
>> *authenticatorName* parameters in *authenticatorConfig*, allow it to
>> pass any additional parameters to IdP (from that SP) so we won't ended up
>> with the need of multiple resident idp to adequate different service
>> providers requirements.
>>
>>
>>> But it doesn't make sense to specially treat to the local authenticator
>>> in SP side and we can consider it also as another idp.
>>>
>> We can name it as resident-idp and SP authenticator can point the idp
>>> name when it want to use local one as same as it use federated one.
>>> We can keep other resident identity provider configuration like password
>>> policies, login policies, etc.. in separate config file that is decouple
>>> with the outbound authentication flow.
>>>
>>
>> What about provisioning configurations? where does that configs going to
>> be in.. If the file name going to be *resident-idp* then all the
>> configurations should be in that file when IS acting as a IdP.
>>
>> WDYT?
>>
>> Regards,
>> Darshana.
>>
>>
>>> This will not effect for the existing framework implementation but only
>>> change the user experience that is more cleaner than now. I have attached
>>> the sample sp file, sample idp file and resident idp file with this, it
>>> would be great if i can get more feedbacks about this.
>>>
>>> thanks
>>>
>>> *Harsha Thirimanna*
>>> *Associate Tech Lead | WSO2*
>>>
>>> Email: hars...@wso2.com
>>> Mob: +94715186770 <+94%2071%20518%206770>
>>> Blog: http://harshathirimanna.blogspot.com/
>>> Twitter: http://twitter.com/harshathirimann
>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>>> rsha-thirimanna/10/ab8/122
>>> 
>>>
>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>> Middleware
>>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Farasath Ahamed]

In the sample.yaml Service Provider configuration I noticed that we have
SAML related SP configurations in two sections "requestHandlerConfigs" and
"responseHandlerConfigs".

Do we need this separation? Is there any advantage of decoupling request
and response related configurations related to an Inbound Protocol like
SAML or OAuth2?


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 




On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana 
wrote:

> +1 for this approach in general...
>
> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
> wrote:
>
>> Hi All,
>>
>> Since we are moving to file base deployment for sp/idp, we have to create
>> these files using yaml. While doing that we thought to resolve some issues
>> and generalize the sp/idp files.
>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>> federated authenticator in IDP file.
>>
>
> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
> not define local authenticator configs in SP.. rather we associate local
> authenticators to the SP.. The issue we had was, there is no way to
> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
> to generate UI elements to resident IdP section, so someone need, they can
> write a new local authenticator and configure it from the resident idp..
>
> Basically you propose the same approach for the IS 6.0.0 with the file
> based configs..
>
> One improvement we can do is, rather than limiting to *idpName* and
> *authenticatorName* parameters in *authenticatorConfig*, allow it to pass
> any additional parameters to IdP (from that SP) so we won't ended up with
> the need of multiple resident idp to adequate different service providers
> requirements.
>
>
>> But it doesn't make sense to specially treat to the local authenticator
>> in SP side and we can consider it also as another idp.
>>
> We can name it as resident-idp and SP authenticator can point the idp name
>> when it want to use local one as same as it use federated one.
>> We can keep other resident identity provider configuration like password
>> policies, login policies, etc.. in separate config file that is decouple
>> with the outbound authentication flow.
>>
>
> What about provisioning configurations? where does that configs going to
> be in.. If the file name going to be *resident-idp* then all the
> configurations should be in that file when IS acting as a IdP.
>
> WDYT?
>
> Regards,
> Darshana.
>
>
>> This will not effect for the existing framework implementation but only
>> change the user experience that is more cleaner than now. I have attached
>> the sample sp file, sample idp file and resident idp file with this, it
>> would be great if i can get more feedbacks about this.
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> *Associate Tech Lead | WSO2*
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770 <+94%2071%20518%206770>
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
> Middleware
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Harsha Thirimanna]

On Thu, Feb 9, 2017 at 12:32 AM, Darshana Gunawardana 
wrote:

> +1 for this approach in general...
>
> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna 
> wrote:
>
>> Hi All,
>>
>> Since we are moving to file base deployment for sp/idp, we have to create
>> these files using yaml. While doing that we thought to resolve some issues
>> and generalize the sp/idp files.
>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>> federated authenticator in IDP file.
>>
>
> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
> not define local authenticator configs in SP.. rather we associate local
> authenticators to the SP.. The issue we had was, there is no way to
> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
> to generate UI elements to resident IdP section, so someone need, they can
> write a new local authenticator and configure it from the resident idp..
>
> Basically you propose the same approach for the IS 6.0.0 with the file
> based configs..
>
> One improvement we can do is, rather than limiting to *idpName* and
> *authenticatorName* parameters in *authenticatorConfig*, allow it to pass
> any additional parameters to IdP (from that SP) so we won't ended up with
> the need of multiple resident idp to adequate different service providers
> requirements.
>
>
>> But it doesn't make sense to specially treat to the local authenticator
>> in SP side and we can consider it also as another idp.
>>
> We can name it as resident-idp and SP authenticator can point the idp name
>> when it want to use local one as same as it use federated one.
>> We can keep other resident identity provider configuration like password
>> policies, login policies, etc.. in separate config file that is decouple
>> with the outbound authentication flow.
>>
>
> What about provisioning configurations? where does that configs going to
> be in.. If the file name going to be *resident-idp* then all the
> configurations should be in that file when IS acting as a IdP.
>
> ​Yes, provisioning ​also with the resident idp, because normal IDP and
Resident IDP both are same except the authenticator change. All the other
resident IDP configuration going to be separate as a runtime config in IS.
May be in Admin portal UI as well.



> WDYT?
>
> Regards,
> Darshana.
>
>
>> This will not effect for the existing framework implementation but only
>> change the user experience that is more cleaner than now. I have attached
>> the sample sp file, sample idp file and resident idp file with this, it
>> would be great if i can get more feedbacks about this.
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> *Associate Tech Lead | WSO2*
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770 <+94%2071%20518%206770>
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
> Middleware
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Darshana Gunawardana]

+1 for this approach in general...

On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna  wrote:

> Hi All,
>
> Since we are moving to file base deployment for sp/idp, we have to create
> these files using yaml. While doing that we thought to resolve some issues
> and generalize the sp/idp files.
> As we have now in IS 5.3.0, we configure local authenticator in SP and
> federated authenticator in IDP file.
>

But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
not define local authenticator configs in SP.. rather we associate local
authenticators to the SP.. The issue we had was, there is no way to
configure local authenticators from the UI.. In IS 5.3.0 we provided a way
to generate UI elements to resident IdP section, so someone need, they can
write a new local authenticator and configure it from the resident idp..

Basically you propose the same approach for the IS 6.0.0 with the file
based configs..

One improvement we can do is, rather than limiting to *idpName* and
*authenticatorName* parameters in *authenticatorConfig*, allow it to pass
any additional parameters to IdP (from that SP) so we won't ended up with
the need of multiple resident idp to adequate different service providers
requirements.


> But it doesn't make sense to specially treat to the local authenticator in
> SP side and we can consider it also as another idp.
>
We can name it as resident-idp and SP authenticator can point the idp name
> when it want to use local one as same as it use federated one.
> We can keep other resident identity provider configuration like password
> policies, login policies, etc.. in separate config file that is decouple
> with the outbound authentication flow.
>

What about provisioning configurations? where does that configs going to be
in.. If the file name going to be *resident-idp* then all the
configurations should be in that file when IS acting as a IdP.

WDYT?

Regards,
Darshana.


> This will not effect for the existing framework implementation but only
> change the user experience that is more cleaner than now. I have attached
> the sample sp file, sample idp file and resident idp file with this, it
> would be great if i can get more feedbacks about this.
>
> thanks
>
> *Harsha Thirimanna*
> *Associate Tech Lead | WSO2*
>
> Email: hars...@wso2.com
> Mob: +94715186770 <+94%2071%20518%206770>
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> 
>



-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859*Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture