I think we can run Java code as part of puppet configuration, if so we can
write a web service client to do this. But I don't think that effort is
really needed since this is to after all support something in our platform.

So +1 to keep the file.


On Tue, Sep 24, 2013 at 10:28 AM, Dulanja Liyanage <[email protected]> wrote:

> Hi all,
>
> Thank you very much for the feedback.
>
> I didn't know about the puppet usecase. Yes, then we'll have to keep this.
>
> Thanks & Regards,
> Dulanja
>
>
> On Mon, Sep 23, 2013 at 6:49 PM, Prabath Siriwardena <[email protected]>wrote:
>
>> Good point Dimuthu..!
>>
>> I think we need to keep this configuration file.
>>
>> First we look for the SAML trusted SP configuration from the Tenant's
>> registry - in case of super tenant, that'll be super tenant registry - if a
>> match found we use that - if not we look for the configuration file. In
>> that way - any tenant can use its own trusted SPs.
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Mon, Sep 23, 2013 at 6:20 PM, Dimuthu Leelarathne 
>> <[email protected]>wrote:
>>
>>> 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
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>
>
>
> --
> Dulanja Liyanage
> Senior Software Engineer - WSO2 Inc.
> M: +94776764717
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Software Engineer
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+94777776950*
Blog - *http://nallaa.wordpress.com*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to