Authentication & Resource Sharing over the Web: OAuth protocol

If you reached this blog and you are not a Mule user (yet) keep reading, I will not cover anything Mule specific. If you are new to OAuth or want to get an introduction to its concepts this post is the right one!
Authentication is vital in any kind of system but it is even more relevant when it comes to the web. As the web grows, more and more sites rely on distributed services and cloud computing. As resources are spread all over the web, sharing them across multiple sites is not an unrealistic requirement considering the following scenarios: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services. In order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else it also provides these applications unlimited access to do as they wish.

The valet key metaphor

I will borrow this metaphor from Eran Hammer-Lahav and use it as starting point to go over OAuth:
“Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.”
How is this related to authentication and OAuth? The regular key would be your user name and password, whoever has them will access your resources without any limit (just as if it were you). So the question is what you can do when you just want to give someone limited access to your resources but without disclosing your credentials and at the same time being able to revoke the access at any time. Keeping this things in mind we can resume what we want from an authentication method:

give partial/restricted access to the protected resources;
avoid disclosing your credentials to a third party site;
revoke access to these resources at any time.

OAuth

The solution to this problem is OAuth. OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.). I will leave the details of OAuth 1.0 and OAuth 2.0 to a later post and focus on the basics for now. Associate the following concepts with the valet key metaphor. Stay with me!

Service Provider: a web application that allows access via OAuth.
Resource Owner/User: an individual who has an account with the Service Provider.
Consumer: a website or application that uses OAuth to access the Service Provider on behalf of the User.
Protected Resource: data controlled by the Service Provider, which the Consumer can access through authentication.

Have you figured out how these terms map with the valet key metaphor? The Protected Resource is the luxury car. The Resource Owner is the owner of the car. The consumer is the parking attendant. The Service Provider well… it is not very clear… the Resource Owner is also the Service Provider because it not only owns the resources but has the means to provide access to them.
The Resource Owner instead of giving the credentials to the Consumer, authenticates against the Service Provider and Service Provider passes a Token to the Consumer with which it can access the Protected Resources. This Token provides limited access to the resources, for example it will not be possible for the Consumer to change the Resource Owner’s password as it can happen when passing the user name and password! Additionally, the Resource Owner can revoke access at any time, invalidating the Token the Consumer has.

Conclusion

I have not yet dealt with the complexities of OAuth (version 1.0 in particular) but as you can see this mechanism allows sharing resources across multiple sites in a safe way. Also, the user who owns these resources is in control of the situation as he/she can revoke access to third part sites at any time. In most sites you have an “Application” menu in your personal settings where it lists all of the sites you allowed access and gives you the option to cancel their access. The terminology can be confusing so just make sure you remember the valet key story and the concepts will clearly emerge.
In my next post I will go over OAuth 1.0 flow and then finally I will show how Mule can help you easily build integrations around APIs that use OAuth. Stay tuned!
Follow: @mulejockey @federecio

Source : http://blogs.mulesoft.org/authentication-resource-sharing-over-the-web-oauth-protocol/

Encrypting passwords in Mule

Jasypt is an open source Java library which provides basic encryption capabilities using a high-level API. This library can be used with Mule to avoid clear text passwords for connectors and endpoints.First, download the latest Jasypt distribution, unpack it and copy icu4j and jasypt jars to MULE_HOME/lib/user directory.

Then add the following snippet to your Mule config file:

        
          
          <!-- -->
<!-- Configuration for encryptor, based on environment variables. -->
<!-- -->
<!-- In this example, the encryption password will be read from an -->
<!-- environment variable called "MULE_ENCRYPTION_PASSWORD" which, once -->
<!-- the application has been started, could be safely unset. -->
<!-- -->
<spring:bean id="environmentVariablesConfiguration"
class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
<spring:property name="algorithm" value="PBEWithMD5AndDES" />
<spring:property name="passwordEnvName" value="MULE_ENCRYPTION_PASSWORD" />
</spring:bean>
<!-- -->
<!-- The will be the encryptor used for decrypting configuration values. -->
<!-- -->
<spring:bean id="configurationEncryptor" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
<spring:property name="config" ref="environmentVariablesConfiguration" />
</spring:bean>
<!-- -->
<!-- The EncryptablePropertyPlaceholderConfigurer will read the -->
<!-- .properties files and make their values accessible as ${var} -->
<!-- -->
<!-- Our "configurationEncryptor" bean (which implements -->
<!-- org.jasypt.encryption.StringEncryptor) is set as a constructor arg. -->
<!-- -->
<spring:bean id="propertyConfigurer"
class="org.jasypt.spring.properties.EncryptablePropertyPlaceholderConfigurer">
<spring:constructor-arg ref="configurationEncryptor" />
<spring:property name="locations">
<spring:list>
<spring:value>credentials.properties</spring:value>
</spring:list>
</spring:property>
</spring:bean>

        
view raw

            JasyptConfig.xml

            hosted with ❤ by GitHub

          

Next, you will need to encrypt your passwords using Jasypt command
line tools. For example, if your Mule application connects to the MySql
database using password “dbpassword”, encrypt it using the following
command:

        
          $ ./encrypt.sh input="dbpassword" password=MyEncryptionPassword algorithm=PBEWithMD5AndDES

view raw
gistfile1.txt
hosted with ❤ by GitHub

Where MyEncryptionPassword is your encryption key. This command will produce the following output:

ka56rcI0bDpUWoAhy5Y+PrVvqu/wMCnL

Now create a properties file that will list your encrypted passwords and
place it in your project src/main/resources directory, e.g. credentials.properties:

        
          database.password=ENC(ka56rcI0bDpUWoAhy5Y+PrVvqu/wMCnL)

view raw

            credentials.properties

            hosted with ❤ by GitHub

Note the ENC() around our encrypted password, this is a que for Jasypt that it is dealing with an encrypted value.

Add the name of this file to the list of locations in the
propertyConfigurer bean. Now you can use the property name in your data
source configuration:

        
          <spring:bean id="jdbcDataSource"
class="org.enhydra.jdbc.standard.StandardDataSource" destroy-method="shutdown">
<spring:property name="driverName" value="com.mysql.jdbc.Driver" />
<spring:property name="url" value="jdbc:mysql://localhost/db1" />
<spring:property name="user" value="dbuser" />
<spring:property name="password" value="${database.password}" />
</spring:bean>

view raw

            jdbcdatasource.xml

            hosted with ❤ by GitHub

Finally, create a system variable with the same name as the value of the passwordEnvName property in the first snippet, e.g. MULE_ENCRYPTION_PASSWORD and set its value to the encryption key used for the encrypting your password, e.g.:

        
          $ export MULE_ENCRYPTION_PASSWORD=MyEncryptionPassword

view raw
gistfile1.txt
hosted with ❤ by GitHub

Thats it. You can now encrypt all passwords or any other values and Mule can read them and it starts up. source : http://blogs.mulesoft.org/encrypting-passwords-in-mule/