Hi Amila,

Thanks for the feedback and will concern about these when we achieve this.

thanks


*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* <http://www.apache.org/>*
*email: **[email protected]* <[email protected]>* cell: +94 71 5186770 *
*twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
*harshathirimannlinked-in: **http:
<http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
<http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*

*Lean . Enterprise . Middleware*


On Tue, Jul 21, 2015 at 5:58 PM, Amila Maha Arachchi <[email protected]>
wrote:

> Adding SPs and IDPs via config files is very useful when managing
> deployments. What if we provide a config file to add SPs and IDPs. At
> server start, relevant component reads it and stores the config in
> registry. So, other members in the cluster can get that info from the
> registry. This will only be usable for super tenant mode. These configured
> SPs and IDPs should be shown in the UI. If edited from UI, it should change
> the registry config. But if that change is not in the config file, in the
> next restart, it will get overwritten by the file. i.e. config file has
> precedence over ui.
>
> For tenants, this has to be allowed via the UI. When a SP or IDP is added
> from UI, it should be stored in registry.
>
> There is following option as well. That is to write a deployer for this as
> IS has done in multiple userstore scenario. Then we will need dep-sync to
> sync the config file across the cluster.
>
> IMO, first approach will cause less problems. But the second approach
> looks clean.
>
> On Tue, Jul 21, 2015 at 8:16 AM, Harsha Thirimanna <[email protected]>
> wrote:
>
>> Hi Prabath,
>>
>> Registry based dep-sync is not used and it is not supported anymore.
>> Yes we are not going to implement any of this in this release. Only
>> concern was without giving different solution for different places , wanted
>> to get some generic solution for at least next release.
>> I will create a public jira as an improvement for this and will concern
>> next release.
>>
>> Thanks
>> On Jul 20, 2015 7:31 PM, "Prabath Siriwardena" <[email protected]> wrote:
>>
>>> I think one common problem we need to address is to deploy service
>>> providers/ identity providers across tenants...
>>>
>>> If we use a file based approach - we should only use that. Do we have
>>> the registry-based dep-sync working now..?
>>>
>>> Also -1 to do any of the changes to 5.1.0 - its already months late..
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Mon, Jul 20, 2015 at 2:12 AM, Harsha Thirimanna <[email protected]>
>>> wrote:
>>>
>>>> Hi All,
>>>> Since we support file base deployment for SP/IDP, we should have
>>>> consistent mechanism to deploy it in clustered environment.
>>>>
>>>> *How it works now*
>>>> We can create SP and IDP from UI and it is stored in data base, for
>>>> both super tenant and multi-tenant mode.
>>>> In file base, we can only create super tenant SP/IDP. It is also not
>>>> show in the UI.
>>>>
>>>> *Problems*
>>>> When we create IDP or SP in file, we update the database and retrieve
>>>> from database when it wants. Every time when restart the node, we
>>>>  re-deploy all the idp configs. In cluster mode, we have to maintain same
>>>> config file in all the node, otherwise wrong file may be updated or some
>>>> other node will delete from database if some files not available in there.
>>>> In claim deployment, we deployed claims from config file only in very
>>>> first start of the server. So after that we can't change the file. We have
>>>> to go to the UI. If we solve that problem to deploy when it change, then
>>>> above pattern can be seen again.
>>>>
>>>> *Suggesion*
>>>> If we consider these are as deploy-able artifact, then we can move
>>>> these in to the deployment path and allow to dep-synch work. In that case ,
>>>> only concern is adding configs to the database or not.
>>>> OR
>>>> We can keep as same now and write simple deployment component base on
>>>> database. We can delete config file  just after update the database from
>>>> file and let user to edit from UI. If user want to change from file only,
>>>> then he can put new config again and it will udpate database again and
>>>> delete file in local. Then we don't want to put any file in to the other
>>>> node in cluster. But  if we put another config file in other node, then it
>>>> will update the database(but not a big issue).
>>>> OR
>>>> As same as second option in above, we can update database from reading
>>>> file and keep the file as it is without deleting from locally. To do that
>>>>  we have to create a config to allow , one specific node to do the update
>>>> and others are not. All the config can be seen from the UI and allow to
>>>> edit.
>>>>
>>>> WDYT ?
>>>>
>>>> *Harsha Thirimanna*
>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>>>> * <http://www.apache.org/>*
>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 *
>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
>>>> *harshathirimannlinked-in: **http:
>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
>>>>
>>>> *Lean . Enterprise . Middleware*
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Twitter : @prabath
>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>
>>> Mobile : +1 650 625 7950
>>>
>>> http://blog.facilelogin.com
>>> http://blog.api-security.org
>>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Amila Maharachchi*
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
>
> Blog: http://maharachchi.blogspot.com
> Mobile: +94719371446
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to