I also think Sanjiva's design is correct. Storing the actual encrypted value in the config is not right. For example, we are going to want to have pre-defined integration "recipes" in the iPaaS so that users can just grab one. Sanjiva's design makes that easier.
Does the existing secure vault support Multi-Tenancy? We definitely need that. Paul On 21 July 2013 07:11, Sanjiva Weerawarana <[email protected]> wrote: > I don't understand this design ... > > I though the secure vault design was allows something like this: > > <twitter.config> > <parameter name="oauth.consumerSecret" value="{vault-lookup('twitter. > oauth.consumerSecret')}"/> > </t.c> > > In other words the value is either a literal value or something looked up > from the vault. I think we currently use a different attribute when we're > getting values from the vault but the above XPath approach seems much nicer > to me. > > Then, in the UI you'd have to have a place where to user can store a value > for that key in the secure vault. If hand-editing, we need to provide a > tool/mechanism to get the value into the vault. > > In no scenario with this model is the actual encrypted string showing up > in the config - that's just plain ugly if nothing else. > > Sanjiva. > > > On Sun, Jul 21, 2013 at 10:52 AM, Dushan Abeyruwan <[email protected]>wrote: > >> Hi All >> >> I have done required changes in synapse, there won't be any existing >> API's effected due to the given changers , so the overall process will be >> as shown in [1] where attributes required encryption required to embedded a >> key [*enc:] *so during the serialization it will be saved as [2], and >> during run-time those encrypted values will be decrypted using the * >> WSO2MediationSecurityInterceptor* ], the give solution >> has implemented and tested in scratch environment and works as expected. >> >> >> [1] before saving to configuration embedded enc: for the filed which >> requires encryption >> >> <twitter.config> >> <parameter name="oauth.consumerSecret" >> value="*enc:*mmmmmmmmmmmmmmm"/> >> <parameter name="oauth.accessTokenSecret" >> value="*enc:*xxxxxxx"/> >> <parameter name="oauth.accessToken" >> value="*enc:*eeeeeee"/> >> <parameter name="oauth.consumerKey" value="eeeexxxxxx"/> >> </twitter.config> >> <twitter.search> >> <parameter name="search" value="hotel"/> >> </twitter.search> >> >> [2] once serialized the values will be encrypted using wso2carbon key >> store values >> algorithm of encryption >> >> * /*** >> * * Encrypt a given plain text* >> * * * >> * * @param plainTextBytes* >> * * The plaintext bytes to be encrypted* >> * * @return The cipher text bytes* >> * * @throws CryptoException* >> * * On error during encryption* >> * */* >> * public byte[] encrypt(byte[] plainTextBytes) throws CryptoException {* >> * try {* >> * >> * >> * KeyStoreManager keyMan = KeyStoreManager.getInstance(* >> * MultitenantConstants.SUPER_TENANT_ID, this.serverConfigService,* >> * this.registryService);* >> * KeyStore keyStore = keyMan.getPrimaryKeyStore();* >> * >> * >> * Certificate[] certs = keyStore.getCertificateChain(keyAlias);* >> * Cipher cipher = Cipher.getInstance("RSA", "BC");* >> * cipher.init(Cipher.ENCRYPT_MODE, certs[0].getPublicKey());* >> * >> * >> * return cipher.doFinal(plainTextBytes);* >> * >> * >> * } catch (Exception e) {* >> * e.printStackTrace();* >> * throw new CryptoException(Messages.getMessage("erorDuringEncryption"), >> e);* >> * }* >> * }* >> >> <twitter.config> >> <parameter name="oauth.consumerSecret" >> value="*encrypted:* >> K+PTyrN7K1KM2kOeFKMv0x9X5EP9qCpS7mJm9mpi9p3FqyYNyd1qCAlHKMA6dXAkCg1mdzL0TvF9ApMjwuVUoijO/C3EWn6Pf4Ju+70e2rsJ3hrbUVuD/SI/NaxS0QAg9mJzg/p0frnugbC+uha85d32yotUWcosKHW26Yjb6Ao="/> >> <parameter name="oauth.accessTokenSecret" >> value="*encypted:* >> WfUb4sTrimV/WDjER8UldK2E2ez/0kC8r3RUWL3o0Lfuq+uZwjJxfIn3YYwRcPT52FSriKdesNg9Hi6sHW2gN4NqyI9pFqG1L3sfDwnlS0u4RAl8ZLq+62rUuVhA2C+XORyEBp8AZYUf1ew1dUSf8LG/+NfyoHmiLmwO3MvPqbo="/> >> <parameter name="oauth.accessToken" >> value="*encypted:* >> FK2gv27JwmPrR7wybWI732HDQlR6p4jPlbTJQJKga386yGJ43gYpFsgoeilhDz/24tEe+4IqSuajsrWFa7wi8Ot6p+bLsufartodJhHt6zQfNTq6yaVzZWUExRjV2bsnJ477yfwc4Oz30c59rhZvkNtGkXXaVp8Fo1nlS18H3mQ="/> >> <parameter name="oauth.consumerKey" >> value=*"*eeeexxxxxx"/> >> </twitter.config> >> <twitter.search> >> >> >> [3] Synapse config >> <definitions xmlns="http://ws.apache.org/ns/synapse";> >> <registry provider="org.wso2.carbon.mediation.registry.WSO2Registry"> >> <parameter name="cachableDuration">15000</parameter> >> </registry> >> * <security >> provider="org.wso2.carbon.mediation.security.WSO2MediationSecurityInterceptor"/> >> * >> >> >> any thoughts or improvements which you guys think ? >> >> >> On Sat, Jul 20, 2013 at 8:45 PM, Dushan Abeyruwan <[email protected]>wrote: >> >>> Hi all, >>> A small correction the relevant config should look like as below >>> described >>> >>> <twitter.config> >>> <parameter name="oauth.consumerSecret" >>> >>> value="*enc:*EvTEzc3jj9Z1Kx58ylNfkpnuXYuCeGgKhkVkziYNMs"/> >>> >>> >>> Cheers >>> Dushan >>> >>> >>> On Sat, Jul 20, 2013 at 8:39 PM, Dushan Abeyruwan <[email protected]>wrote: >>> >>>> Hi >>>> IMO seems like >>>> EntitlementMediato<https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java>r >>>> approach >>>> quite suitable and handy and I would think what it does for the time being >>>> is _ _okay _ _ since Entitlement component is NOT resides within synapse >>>> (need expert suggestion form IS since they are the one who implemented the >>>> current approach) , according to the discussion had (with Kasun at el) >>>> thought how we could probably include the same approach for >>>> the components resides in synapse. >>>> There we have identified the approach which registry getting >>>> intercepted could be useful [2].We thought of introducing a security >>>> related component [3] a kind of extension point where the >>>> SecurityInteceptors will be initialized during init() >>>> and readily available in *synapseConfiguration* during serialization >>>> or during run-time and with that we could probably utilize the attributes >>>> which required for encrypt with special character or sequence as shown [1] >>>> anyway I am still doing a feasibility study of the >>>> described approach, may be there we might have jump few hurdles to get this >>>> done without harming synapse API .. >>>> >>>> really appreciate thoughts from IS for this approach, do you guys >>>> feel any _ _ better more reliable approach than this _ _ ? >>>> >>>> e.g >>>> [1] >>>> <twitter.config> >>>> <parameter name="*enc:*oauth.consumerSecret" >>>> >>>> value="EvTEzc3jj9Z1Kx58ylNfkpnuXYuCeGgKhkVkziYNMs"/> (if used enc: then >>>> during serialization those values encrypited same can be integrated for >>>> UI's even this might not be any issue when use DevS approach as well) >>>> >>>> >>>> >>>> >>>> [2] >>>> <registry provider="org.wso2.carbon.mediation.registry.WSO2Registry"> >>>> <parameter name="cachableDuration">15000</parameter> >>>> </registry> >>>> >>>> [3] >>>> <registry provider="org.wso2.carbon.security.*SecurityInterceptor*"> >>>> *SecurityInterceptor (class name or package not finalized yet)* >>>> <parameter name="cachableDuration">15000</parameter> >>>> </registry> >>>> >>>> >>>> >>>> On Sat, Jul 20, 2013 at 7:17 PM, Sanjiva Weerawarana >>>> <[email protected]>wrote: >>>> >>>>> Dushan connector creds are going to be user specific. So that means >>>>> they have to be able to configure them in a user-accessible way .. and >>>>> then >>>>> the data needs to be stored in a secure vault of some kind. >>>>> >>>>> For UI driven configs that's easy - we get the password in the UI, >>>>> store in the vault and refer to it in the mediator config. >>>>> >>>>> For hand edited synapse.xml stuff you'd need to let the user do the >>>>> same. Do we have a per-user vault type concept? >>>>> >>>>> Sanjiva. >>>>> >>>>> >>>>> On Fri, Jul 19, 2013 at 11:18 AM, Dushan Abeyruwan <[email protected]>wrote: >>>>> >>>>>> Hi >>>>>> Regarding $subject, what would be the best way to accomplish ? >>>>>> According to the EntitlementMediator implementation it >>>>>> seems we are using a different approach as shown below [1], any reason >>>>>> which prevent us moving to synapse secure vault and also seems there are >>>>>> zero documentation related to Synapse secure vault configuration. >>>>>> >>>>>> >>>>>> [1] >>>>>> >>>>>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java >>>>>> >>>>>> >>>>>> public void setRemoteServicePassword(String remoteServicePassword) { >>>>>> if (remoteServicePassword.startsWith("enc:")) { >>>>>> try { >>>>>> * this.remoteServicePassword = new >>>>>> String(CryptoUtil.getDefaultCryptoUtil()* >>>>>> * >>>>>> .base64DecodeAndDecrypt(remoteServicePassword.substring(4)));* >>>>>> } catch (CryptoException e) { >>>>>> log.error(e); >>>>>> } >>>>>> } else { >>>>>> this.remoteServicePassword = remoteServicePassword; >>>>>> } >>>>>> } >>>>>> >>>>>> Cheers, >>>>>> Dushan Abeyruwan >>>>>> Associate Tech Lead >>>>>> *Integration Technologies Team* >>>>>> *WSO2 Inc. http://wso2.com/* >>>>>> *Mobile:(+94)714408632* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sanjiva Weerawarana, Ph.D. >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 >>>>> 650 265 8311 >>>>> blog: http://sanjiva.weerawarana.org/ >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dushan Abeyruwan >>>> Associate Tech Lead >>>> *Integration Technologies Team* >>>> *WSO2 Inc. http://wso2.com/* >>>> *Mobile:(+94)714408632* >>>> >>> >>> >>> >>> -- >>> Dushan Abeyruwan >>> Associate Tech Lead >>> *Integration Technologies Team* >>> *WSO2 Inc. http://wso2.com/* >>> *Mobile:(+94)714408632* >>> >> >> >> >> -- >> Dushan Abeyruwan >> Associate Tech Lead >> *Integration Technologies Team* >> *WSO2 Inc. http://wso2.com/* >> *Mobile:(+94)714408632* >> > > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | > +1 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, Apache Member UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo [email protected] wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
