On Wed, Feb 15, 2017 at 10:54 PM, Ishara Karunarathna <isha...@wso2.com> wrote:
> > > On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna <hars...@wso2.com> > wrote: > >> >> >> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed <farasa...@wso2.com> >> 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 <https://twitter.com/farazath619> >>> <http://wso2.com/signature> >>> >>> >>> >>> On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana <darsh...@wso2.com >>> > wrote: >>> >>>> +1 for this approach in general... >>>> >>>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna <hars...@wso2.com> >>>> 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 >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> >>>> *Darshana Gunawardana*Associate Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> >>>> *E-mail: darsh...@wso2.com <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 > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
