On Mon, Jul 22, 2013 at 8:27 AM, Sanjiva Weerawarana <[email protected]>wrote:
> Amila +1 for losing <parameter> and using elements directly - since we're
> auto generating these mediators we should be able to make the change
> easily. Kasun what do you think?
>
> On @key vs. @foo="{xxx}" model, the problem with @key is that its a
> special attribute that has to be checked everywhere. If we say an attribute
> value or an element value is always a literal value or an XPath expression
> to evaluate ("{xpath-expresssion}") then its very powerful and flexible.
> That can also be implemented trivially via a util method.
>
without doubt I am + 1 for the approach and it can be done
>
> The model of using vault-lookup() will work in the dev/test/stage/prod
> lifecycle path as well - just use different vaults for the data.
>
> Sanjiva.
>
>
> On Mon, Jul 22, 2013 at 7:10 AM, Amila Suriarachchi <[email protected]>wrote:
>
>>
>>
>>
>> On Sat, Jul 20, 2013 at 10:22 PM, 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"/>
>>>
>>
>> I am not a fan of this parameter concept :). For me something like this
>> is more user friendly.
>>
>> <oauth.consumerSecret>*enc:*mmmmmmmmmmmmmmm</oauth.consumerSecret>
>>
>> thanks,
>> Amila.
>>
>>
>>
>>
>>> </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*
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Amila Suriarachchi*
>>
>> Software Architect
>> WSO2 Inc. ; http://wso2.com
>> lean . enterprise . middleware
>>
>> phone : +94 71 3082805
>>
>> _______________________________________________
>> 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*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
