Hi Harsha, On Thu, Feb 9, 2017 at 12:32 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.. > > 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 >> <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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
