On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed <[email protected]> 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 <https://twitter.com/farazath619> > <http://wso2.com/signature> > > > > On Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana <[email protected]> > wrote: > >> +1 for this approach in general... >> >> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna <[email protected]> >> 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: [email protected] >>> 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: [email protected] <[email protected]>* >> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >> Middleware >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
