Hi Prabath, I believe that this is not possible with current IS (am right..?). Or is there a way to do this without changing the code (may be by a configuration).
Thanks SumedhaS On Thu, Jan 16, 2014 at 8:57 AM, Prabath Siriwardena <[email protected]>wrote: > Solution to this is have a WSO2 CA. > > Currently all tenants have self-signed certificates in their key store. > Ideally we should sign all these from the WSO2 CA. > > Then, in the SAML response, you can validate whether the response is > signed from a certificate issued by the root CA. > > Thanks & regards, > -Prabath > > > > On Thu, Jan 16, 2014 at 8:58 PM, Sumedha Kodithuwakku > <[email protected]>wrote: > >> Hi Prabath, >> >> Think a scenario like this. >> >> I have a application which do the authentication with IS via SAML2 SSO. >> And the app then use the SAML2 assertion for getting a OAuth token (IS is >> configured as a key manager and use Application use this token to do a API >> call in APIM). >> >> Now I register the app as a Service provider in each tenant. Also I will >> register IS as a Trusted Identity provider in each tenant. I use the public >> certificate of the default carbon keysotre (which is in supper tenants >> space). But this will only work for supper tenant. The reason being when I >> log in using SAML2 SSO the response and assertion is signed using that >> particular tenants private key (In supper tenants case the key from >> wso2carbon.jks). >> >> When I try to get the OAuth token, it cannot verify the Assertion since I >> have used the default public key from wso2carbon.jks. If I use the tenants >> public key this will succeed. I believe that this is the correct approach. >> However if we have multiple tenants this can become difficult to maintain. >> >> Also it is not possible to delete the created keysotre of a tenant also >> (or is there a way..?) and use a new one. >> >> Thanks >> SumedhaS >> >> >> On Thu, Jan 16, 2014 at 1:59 AM, Prabath Siriwardena <[email protected]>wrote: >> >>> No.. why do you want to do that ? We are creating a key store per tenant. >>> >>> Thanks & regards, >>> -Prabath >>> >>> >>> On Thu, Jan 16, 2014 at 2:24 PM, Sumedha Kodithuwakku <[email protected] >>> > wrote: >>> >>>> Hi all, >>>> >>>> Is it possible to $subject. >>>> >>>> Although I added it via UI (for particular tenant with a different >>>> name) it won't be used to signing purposes. The Private Key from the auto >>>> generated keystore will be used. For example if I do a SAML2 SSO login, the >>>> above key will be used to signing response and assertion. Because of this >>>> reason we need to configure IDP of tenants with their own public cert, if >>>> we do SAML2 Bearer Assertion Profile for OAuth 2.0 kind of a scenario. >>>> >>>> Is there any way to use the default carbon keystore for this..? >>>> >>>> Thanks >>>> SumedhaS >>>> >>>> -- >>>> *Sumedha Kodithuwakku* >>>> Software Engineer >>>> WSO2 Inc. : wso2.com >>>> lean . enterprise . middleware >>>> >>>> Email: [email protected]; Mobile: +94 71 808 1124 | +1 602 388 0160 >>>> Blog: http://sumedhask.blogspot.com/ >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Twitter : @prabath >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://blog.api-security.org >>> >> >> >> >> -- >> *Sumedha Kodithuwakku* >> Software Engineer >> WSO2 Inc. : wso2.com >> lean . enterprise . middleware >> >> Email: [email protected]; Mobile: +94 71 808 1124 | +1 602 388 0160 >> Blog: http://sumedhask.blogspot.com/ >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://blog.api-security.org > -- *Sumedha Kodithuwakku* Software Engineer WSO2 Inc. : wso2.com lean . enterprise . middleware Email: [email protected]; Mobile: +94 71 808 1124 | +1 602 388 0160 Blog: http://sumedhask.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
