Sunday, August 31, 2014

Creating your own OAuth2 server and clients using spring security - part 3

So now it's time to test our configuration live!

we will need an apache tomcat server and mysql db server, I'll use tomcat 7 and wamp for db

but before that there is a few things to add to make our test meaningful, we will add an mvc-rest controller that will be protected by our security implementation:

then modify the mvc-dispatcher-servlet.xml to see this new controller by adding:

<context:component-scan base-package="com.blabadi">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
which basically tells spring to scan for controller annotation under the base package

important points here:
- spring mvc requires to have a context for its servlets that is different than the context of the application, that's why we have a different configuration files : spring-beans and mvc-dispatcher-servlet.xml

- we don't scan controllers in the root context because that will create duplicated instances for them
- the dispatcher servlet is required for both : spring security web and rest services

run the command maven package to our application and deploy the war
if you get this after deployment in tomcat console then you're good to continue :
Now use your favorite rest client to try to access the protected service, here I used postman chrome app :

so our configurations are working, we were able to prevent unauthenticated access to this service, lets try to get authenticated by getting a token:

now we have the token, lets use it:

Awesome! we have fully tested a simple password grant type OAuth2 scenario from end to end!

happy coding..

In the future we will implement another grants and add more scenarios on this project

Creating your own OAuth2 server and clients using spring security - part 2

so we continue our OAuth2 journey, in this part I plan to explain the entries we have in spring-security.xml

lets start..

first part in the xml file is this:
<oauth:resource-server id="resourceServerFilter"
resource-id="custom_app" token-services-ref="tokenServices" />
this defines that this is a resource server (secured information source) for OAuth2, which means this server will be accessed by OAuth2 clients to get infromation/data from.

client-details-service-ref="clientDetails" token-services-ref="tokenServices"
<oauth:authorization-code />
<oauth:implicit />
<oauth:refresh-token />
<oauth:client-credentials />
<oauth:password />
 this part means that we want to create an authorization server that supports the listed OAuth2 flows:
1- authorization code
2- implicit
3- referesh token

OAuth2 is designed to support multiple use cases that clients may need, for example a 3rd party application may want to access data on our server about some user, we don't want our user to give his password to that 3rd party app, we want our user to login on our web interface and then we will give that application a temporary access to the user data [authorization-code flow]

but if we want the user to login to one of our trusted applications we can simply ask him for his user name and password once then generate a token to use it when we need [password flow]

I don't know about all flows but adding them here won't harm us for now.

let's continue on the other xml entries:

<!-- clients service -->
<oauth:client-details-service id="clientDetails">
<oauth:client client-id="mobile_iphone"
authorized-grant-types="password,refresh_token,implicit" secret="custom_app_iphone"
authorities="ROLE_CLIENT" />
<oauth:client client-id="mobile_android"
authorized-grant-types="password,refresh_token,implicit" secret="custom_android"
authorities="ROLE_CLIENT" />
<oauth:client client-id="web_liferay"
authorized-grant-types="password,refresh_token,implicit" secret="custom_liferay"
authorities="ROLE_CLIENT" />
 the above segment defines the list of clients that are recognized by our oauth2 server to request access on our users data, in large scale applications where there are many 3rd party clients it's better to use db to store these, but for our case it's enough to hard code them in our xml file.
here we have 3 applications : iphone app, web app, android app that will communicate with our server.

<oauth:expression-handler id="oauthExpressionHandler" />
<oauth:web-expression-handler id="oauthWebExpressionHandler" />

 the above are handlers to parse expressions used in the configuration here and in the application ( security annotation as we will see later)

Token configurations
<bean id="tokenStore" class="" />
<bean id="jdbcTokenStore"
<constructor-arg ref="secDataSource" />
<bean id="tokenServices"
<property name="tokenStore" ref="jdbcTokenStore" />
<property name="supportRefreshToken" value="true" />
<property name="clientDetailsService" ref="clientDetails" />

In this part we configure the token storage to use our db and configure the token service to use our store.

<!-- token obtaining URL configurations -->
<http pattern="/oauth/token/**" create-session="stateless"
<intercept-url pattern="/oauth/token/**" access="IS_AUTHENTICATED_FULLY" />
<anonymous enabled="false" />
<http-basic entry-point-ref="clientAuthenticationEntryPoint" />
<!-- include this only if you need to authenticate clients via request
parameters -->
<custom-filter ref="clientCredentialsTokenEndpointFilter"
<access-denied-handler ref="oauthAccessDeniedHandler" />

this part configures the URL the clients will  call to obtain a token and it's security conditions such as only authenticated clients are allowed to request tokens, this is required to protect the token endpoint since it's not implicitly protected by spring security oauth

<!-- OAuth 2 related beans -->
<bean id="oauthAccessDeniedHandler"
class="" />
<bean id="clientCredentialsTokenEndpointFilter"
<property name="authenticationManager" ref="clientAuthenticationManager" />

The above two beans are required for other beans, the access denied handler will send status 403 in case a user tries to access a resource that he can't access

the second bean is responsible to authenticate clients using request parameters.

<bean id="accessDecisionManager" class=""
<bean class="" />
<bean class="" />
<!-- required to use ACL expressions like : hasRole('..') -->
<bean class="" />
<bean class="" />

this bean is responsible to decide, based on the listed voters to allow or disallow user to access the requested resource based on the result of each voter.

<!-- Entry points -->
<bean id="oauthAuthenticationEntryPoint"
<property name="realmName" value="custom_app" />
<bean id="clientAuthenticationEntryPoint"
<property name="realmName" value="custom_app/client" />
<property name="typeName" value="Basic" />
<!-- User approval handler -->
<bean id="userApprovalHandler"
<property name="tokenServices" ref="tokenServices" />
the above beans are piping beans required by spring security

<!-- ========================= OAuth protected urls config ============================== -->
<http pattern="/ws/(.*)" request-matcher="regex"
create-session="never" use-expressions="true" entry-point-ref="oauthAuthenticationEntryPoint"
<sec:anonymous enabled="true" />
<intercept-url pattern="/ws/(.*)\?(wsdl|xsd)(.*)"
access="permitAll" />
<!--<intercept-url pattern="/ws/(.*)" access="hasRole('ROLE_USER')" /> -->
<custom-filter ref="resourceServerFilter" before="PRE_AUTH_FILTER" />
<access-denied-handler ref="oauthAccessDeniedHandler" />
<http pattern="/rest/eidentity/**" security="none"
xmlns="" />
<http pattern="/rest/**" authentication-manager-ref="clientAuthenticationManager"
create-session="never" entry-point-ref="oauthAuthenticationEntryPoint"
<anonymous enabled="false" />
<intercept-url pattern="/rest/**" access="ROLE_USER" />
<custom-filter ref="resourceServerFilter" before="PRE_AUTH_FILTER" />
<access-denied-handler ref="oauthAccessDeniedHandler" />

this part is where you list your protected URLs and what is the security requirements for each of them, for example here we have set a security on our web services API to allow unauthenticated users to access the wsdl/xsd documents 

In webservices unlike rest, each web method doesn't have a single url, which prevents us from specifying security here and to workaround that we can use the security annotations above each method

for rest resources (in this example I have an identity API responsible for login, registration, change password etc..) we allowed all APIs in this service to be accessible by any user

while we protected all other 'rest/**' services URLs to have at least ROLE_USER
note: the patterns are validated against from top to bottom

<bean id="clientDetailsUserService"
<constructor-arg ref="clientDetails" />
<authentication-manager id="clientAuthenticationManager"
<authentication-provider user-service-ref="clientDetailsUserService" />
<authentication-manager alias="authenticationManager"
<authentication-provider ref="customAuthenticationProvider"></authentication-provider>
<user-service id="userDetailsService">
<user name="user" password="password" authorities="ROLE_USER" />
<bean id="customAuthenticationProvider"
class="com.blabadi.sec.oauth.provider.CustomAuthenticationProvider" />
this part is related to spring security, we define our authentication beans for both: clients (3rd party applications) and users (resource owners)

each one of these parties has it's own users service and authentication manager and authentication provider

Note you can have multiple authentication providers for same authentication managers and they will all be called in sequence until the first one to success or all fail.

Enable Standard Pre/Post annotations
====================================== -->
<!--you could also wire in the expression handler up at the layer of the
http filters. See -->
<sec:expression-handler ref="oauthExpressionHandler"  />
the last part is to allow us to use the Pre & Post annotations in security, we will need these in case we want to annotate specific methods, in our case they will be web services methods since we can't specify the URLs, example:

Saturday, August 30, 2014

Creating your own OAuth2 server and clients using spring security - part 1

In this series of posts, I'll try to put together a simple working example on how to create your own OAuth2 server.

if you want to know more on OAuth2 and when to use it as authentication and authorization protocol then you can search about it on google and i'll put some URLs later.

Now I assume you are familiar with java web applications using Spring and maven.

to get started we need to create the server side with all dependencies required and i'll list them here, i'll use maven 2 to ease downloading dependencies for us.


1- Create new maven project with arch type webapp:

2- Add the required depenedencies for spring, spring security, spring-oauth2, hibernate & other libraries (required for this tutorial only you can use other libraries if you like)

3- I used hibernate to automate the creation of the schema required by spring OAuth2 to manage tokens (it's required to have schema created in db if you are using jdbc token store).
I use wamp server and phpmyadmin to create my database

4- Setup hibernate mapping [I used xml file, but I think annotations will work too]
5- Create login service interface and stub implementation

6- Create custom authentication provider

7-Create the properties file required for db conneciton

8-Create spring-security.xml  (we will go over the contents in the next part)

9-Create security-beans.xml to gather spring configurations related to security in one place

10-Create spring-beans.xml to gather all configurations in one file
11-Configure web.xml, and add mvc-dispatcher-servlet.xml

after all this if I didn't forget anything you will have the following (click on the image to see it in original size):

Friday, August 29, 2014

Amazon EC2 - I messed up system file and can't login or fix it

So you tried to be smart ..that's good but you didn't plan ahead

Unix is an OS that can be error intolerant and you can loose the access to your system with a simple change on a file like /etc/sudoers  this file contains infromation and password configuration to ask for password on some commands.

In Amazon EC2 you don't have root password so if you configure that file to require password on some commands like 'sudo' command itself that is required to access this file, you will be locked and can't revert back to the changes.

there is a way though to go around this problem, and basically it's by creating a new instance and attach the broken instance volume to this instance as device and fix what's wrong then relaunch your broken instance.

for example to fix a change on sudoers file with this solution follow the following steps:

1- stop instance we want to fix

2- de-attach it's volume

3- attach it to the new instance [/dev/sdh]

4- start new instance

5- connect with putty

6- create directory to mount 

7- sudo mount device_name mount_point

8- cd [mount_point] > cd etc > vi sudoers

9- modify the file to revert your changes

10- save, exit

11- unmount volume : umount -l [mount_point]

12- stop instance & deattach volume

13- attach to broken instance

14- launch broken instance

Hope this helps!

Saturday, August 23, 2014

EJB called from another, specifically Message driven bean with container transaction.

The other day I had a weird defect in the application I worked on, we had a Message driven bean [MDB] calling another EJB inside the message processing code and everything was working fine and passed two different testing periods.

after going live on production something happened, the MDB received a message and invoked the EJB to do some work, that work included calling a web service, this service client thrown time out exception and thrown an exception and the EJB couldn't finish its work because that's what is expected, the weird thing is that the exact same message was reprocessed by the MDB automatically.. we don't have anything in our code that did that.

this didn't happen before with other EJBs called from an MDB..

after thorough investigation I found the following :

1- The MDB uses container transaction [ found configuration in the ejb-jar.xml] (this is used in EJB2)
2-  The EJB method that was invoked also had container transaction configured with transaction attribute as Required
3- When an exception is thrown from the EJB method, it calls : context.setRollBackOnly(); which means the container transaction will roll back

but why was the message reprocessed again? Luckily in production the service didn't time out the second time and the message was processed successfully, but I did a test where the EJB always fails and that led in having the MDB reprocessing the message indefinitely until I shutdown the server.

I tried and changed the EJB transaction attribute in the ejb-jar.xml to 'RequiresNew' instead of 'Required' because at that point I felt that there is a relation between the transaction failing in the EJB and the MDB transaction [Yes MDBs have transactions] and that WORKED.

it's critical to configure the EJBs [ MDB is an EJB ] transactions to match the need of the application, in our case we didn't want the message to be reprocessed everytime it failed, so a new transaction in the EJB did the trick

Object Oriented Programming .. complex or overrated

In Second year computer science major, I took a whole course on object oriented programming with Java, It was full of new concepts back then and the book was big, but now recently I have been reading a book called growing 'object oriented software guided by testing' .

it has been 3 years since I have graduated and worked in 3 different companies, and while reading that book, the idea that there are so many details and concepts in object oriented that we barely feel we are applying or use in enterprise or medium or small scale applications was on my mind the whole time.

OOP has taken its name from the basic unit of the design which is Objects. However in real applications objects play minor roles and most of the time as VOs (value objects) so the whole concept of objects becomes minor in you're everyday work, there is nothing new about it. Another point is that these objects code are usually IDE generated, for example in eclipse if you're programming Java it takes less than a  minute to write a big class and generate getters/setter (encapsulation).

that doesn't stop here, what makes you really question if OOP is overrated in our major and given more time to teach and learn, is that there are frameworks such as Spring for Java that completely hides the OOP role in programming. What spring does is that, by default, it takes care of initializing and injecting the dependent objects with the objects they depend on, all done by XML or annotations and so there is no need to calling constructors or even writing them.

Spring came to avoid the over head of object oriented, we don't need infinite number of objects to implement the design and do the work. an instance of every object is usually sufficient to handle the job.
here we execlude the VOs from the equation because they are really nothing more than data holders and will not play a critical role in our architecture or design decisions the way we may think.

in summary, I feel although it's important to have a strong foundation in OOP, having a whole course to do it is not needed, OOP concepts are everywhere in our major and they can be focused on when necessary and most of what you will get in a single course will not be recalled because it's not something you need to remember everyday.

Istio —simple fast way to start

istio archeticture (source I would like to share with you a sample repo to start and help you continue your jou...