Yes, from IS 4.1.0 onward we have removed the 'org.wso2.stratos.identity.saml2.sso.mgt' bundle and the sso-idp-config.xml due to the reason it is only used by the Stratos Manager. We can re-add it in the next IS release without any problem.
However, I'm not clear why reading of this file is done by a Stratos bundle in the first place, rather than an Identity one? Regarding setDoSignResponse patch, this is already done by NuwanB for org.wso2.stratos.identity.saml2.sso.mgt:2.2.0. He's introduced a new element to the config file and reading from it. Thanks & Regards, Dulanja On Fri, Sep 27, 2013 at 11:12 AM, Shariq Muhammed <[email protected]> wrote: > Hi folks, > > As discussed its pretty clear that we need to support the sso-idp-config.xml > in > to register SPs. However the released IS 4.5.0 doesn't support this, even > if we create the file in repository/conf/ directory there is no bundle to > parse the config and register the SP. > > Previously we has the org.wso2.stratos.identity.saml2.sso.mgt [1] which > adds the SP via the config file, we added this bundle to Stratos Manageras we > moved the SSO functionality to away from IS. So I guess we have now > dropped this bundle from IS now. > > However in one of our new deployment which uses IS 4.5.0 as the IDP, I > managed to get the SP registration working by patching the saml2.sso.mgt. > bundle (setDoSignResponse to "true") and now everything seems to be > working fine. How about adding this bundle back to IS since we intend to > support the sso-idp-config.xml file in IS ?! If there are no concerns can > someone from the IS team look into this ?! > > [1] - > https://svn.wso2.org/repos/wso2/carbon/platform/tags/4.0.0/components/stratos/sso-mgt/org.wso2.stratos.identity.saml2.sso.mgt/ > > > On Tue, Sep 24, 2013 at 11:39 AM, Prabath Siriwardena <[email protected]>wrote: > >> On Tue, Sep 24, 2013 at 11:16 AM, Johann Nallathamby <[email protected]>wrote: >> >>> 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. >>> >> >> That really does not work - because its an admin service and we also need >> to have credentials - which is not good. >> >> Thanks & regards, >> -Prabath >> >>> >>> 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* >>> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks, > M. S. M. Shariq. > Senior Software Engineer > Phone: +94 777 202 225 > -- Dulanja Liyanage Senior Software Engineer - WSO2 Inc. M: +94776764717
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
