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.

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

Reply via email to