Hi
without doubt I am + 1 for the approach and it can be done:)
>>
>
> +1. And make sure all mediators follow this pattern. Please don't say this
> mediator has done by this team etc ... :). It is ESB teams responsibility
> to have a common standards across all mediators :).
>
Yeah it's ESB team responsibility but I am waiting for the answers from
IS team why they have followed such a Invalid approach in *Entitlement* *
mediator* and they should (Must) answers this because up to now
I haven't hard anything form IS why they took such approach I haven't see
any @arch mail regarding entitlement mediator approach... :(
> thanks,
> Amila.
>
>
>>
>>
>>
>>>
>>> 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
>>
>>
>
>
> --
> *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
>
>
--
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
