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