Hi Ishara, thanks for the feedback,

On Wed, Feb 15, 2017 at 10:49 PM, Ishara Karunarathna <[email protected]>
wrote:

> Hi Harsha,
>
> On Thu, Feb 9, 2017 at 12:32 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..
>>
>> 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: [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
>>
>>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to