Hi Dulanja,

What about cloud deployments? Current config files enable us to puppet-ize
the deployment. When you do this it will no longer be able to do the
deployment.

If the problem is rewriting sso-idp-config.xml each time you add a
parameter, then it is the problem of the code. We can write config file
parsers in a very extensible way. For example refer [1]. We rarely write
our configuration parser.

And if you want to specify super tenant only SPs  you can add a new
parameter.

Since this suggestion doesn't facilitate deployments I am -1 for this. If
you can provide a solution for the deployment then I'll withdraw the -1.

thanks,
dimuthu


[1]
https://svn.wso2.org/repos/wso2/scratch/appfactory/components/appfac/org.wso2.carbon.appfactory.common/1.1.0/src/main/java/org/wso2/carbon/appfactory/common/util/AppFactoryUtil.java


On Mon, Sep 23, 2013 at 6:01 PM, Nuwan Bandara <[email protected]> wrote:

> great
>
>
> On Mon, Sep 23, 2013 at 5:57 PM, Dulanja Liyanage <[email protected]>wrote:
>
>> Hi Nuwan,
>>
>> IS already has IdentitySAMLSSOConfigService for that purpose.
>>
>> Thanks & Regards,
>> Dulanja
>>
>>
>> On Mon, Sep 23, 2013 at 5:47 PM, Nuwan Bandara <[email protected]> wrote:
>>
>>> Hi Dulanja
>>>
>>>
>>> On Mon, Sep 23, 2013 at 5:43 PM, Dulanja Liyanage <[email protected]>wrote:
>>>
>>>> Hi All,
>>>>
>>>> AFAIK, AF and UES products are currently using the 'sso-idp-config.xml'
>>>> file to store the SAML SSO Service Provider (SP) configurations. The main
>>>> purpose of that is to write SP configuration *once* and use it for all
>>>> the tenants. This removes the burden of adding the *same set* of SPs
>>>> for each Tenant via the IdP UI.
>>>>
>>>> However, the downsides of this is, when a new feature/option is added
>>>> to the Identity Server's SP registration page, this file should be *
>>>> also* changed and the file read logic should be modified accordingly.
>>>> To avoid this, we are looking at the possibility of removing the usage of
>>>> that file - allowing changes to be incorporated with minimum effort.
>>>>
>>>> One plausible way is to always save the tenant-shared configurations
>>>> via the SP registration UI of the Super Admin. Since sso-idp-config.xml is
>>>> also configured by the Super Admin, there shouldn't be any harm doing this.
>>>>
>>>> So, to validate the SP when a SAML request comes for a tenant user,
>>>> code logic should first check tenant's own configurations in his registry,
>>>> and if no relevant SP is found (by using the issuer ID), then check Super
>>>> Admin's configuration from the registry for the shared SPs.
>>>>
>>>> But, what if Super Admin wants to maintain a set of SPs only for his
>>>> users. (i.e non-shareable SPs) ?
>>>>
>>>> To cater this, we can introduce a new option to SP registration UI to
>>>> specify whether a particular SP is shared or not.
>>>>
>>>> This would be the first step of improving the tenant story in SAML SSO.
>>>> Appreciate your ideas on this.
>>>>
>>>
>>> +1, for the idea, please provide a service to register SPs, because not
>>> always we use the mgt-console UI to register new SPs.
>>>
>>> Regards,
>>> /Nuwan
>>>
>>>
>>>>
>>>> Thanks & Regards,
>>>> Dulanja
>>>>
>>>> --
>>>> Dulanja Liyanage
>>>> Senior Software Engineer - WSO2 Inc.
>>>> M: +94776764717
>>>>
>>>
>>>
>>>
>>> --
>>> *Thanks & Regards,
>>>
>>> Nuwan Bandara
>>> Technical Lead; **WSO2 Inc. *
>>> *lean . enterprise . middleware |  http://wso2.com *
>>> *blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 214
>>> 5345
>>> *
>>> <http://www.nuwanbando.com/>
>>>
>>
>>
>>
>> --
>> Dulanja Liyanage
>> Senior Software Engineer - WSO2 Inc.
>> M: +94776764717
>>
>
>
>
> --
> *Thanks & Regards,
>
> Nuwan Bandara
> Technical Lead; **WSO2 Inc. *
> *lean . enterprise . middleware |  http://wso2.com *
> *blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 214
> 5345
> *
> <http://www.nuwanbando.com/>
>



-- 
Dimuthu Leelarathne
Architect & Product Lead of App Factory

WSO2, Inc. (http://wso2.com)
email: [email protected]
Mobile : 0773661935

Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to