Jumat, 07 Juni 2013

Implementasi WSI UsernameToken pada grails cxf

Saya ini saya ingin mencoba implementasi Security WSI. Pada proyek ini kita memerlukan domain UserWebservice sebagai penyimpan data username dan password.
 package org.grails.cxf.samplewssecurity1 
class UserWebservice {

    String username
    String password

    static constraints = {
    }
}

Setelah itu kita buat ServerPasswordCallbackHandlerService. Service ini berguna untuk lookup pasangan username dan password
 package org.grails.cxf.samplewssecurity1 
 import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import org.apache.ws.security.WSPasswordCallback
import org.springframework.beans.factory.InitializingBean

class ServerPasswordCallbackHandlerService implements CallbackHandler,InitializingBean{

    @Override
    void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException{
        for (pc in callbacks){
            if(log.debugEnabled){
                log.debug pc.identifier
                log.debug pc.password
            }
            def password= UserWebservice.findByUsername(pc.identifier)?.password 
            if(password) {
                pc.password = password
            }
        }
    }

    @Override
    void afterPropertiesSet() {
    }
}

Kita mempunyai service yang akan proteksi dengan password yang bernama AnnotatedSecureService Seperti dibawah ini.
 package org.grails.cxf.samplewssecurity1 
import org.grails.cxf.utils.EndpointType
import org.grails.cxf.utils.GrailsCxfEndpoint
import org.grails.cxf.utils.GrailsCxfEndpointProperty

import javax.jws.WebMethod
import javax.jws.WebParam
import javax.jws.WebResult

@GrailsCxfEndpoint(expose = EndpointType.JAX_WS,properties = [@GrailsCxfEndpointProperty(name = "ws-security.enable.nonce.cache", value = "false"), @GrailsCxfEndpointProperty(name = "ws-security.enable.timestamp.cache", value = "false")])
class AnnotatedSecureService {

    @WebMethod(operationName = "simpleMethod")
    @WebResult(name = "simpleResult")
    String simpleMethod(@WebParam(name = "param") String param) {
        return param.toString()
    }
}
Kita akan tambahkan di class BootStrap sebagai berikut.
 package org.grails.cxf.samplewssecurity1  
import org.apache.cxf.frontend.ServerFactoryBean
import org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
import org.apache.ws.security.WSConstants
import org.apache.ws.security.handler.WSHandlerConstants
import org.grails.cxf.samplewssecurity1.UserWebservice

class BootStrap {
    ServerFactoryBean annotatedSecureServiceFactory
    def serverPasswordCallbackHandlerService
    def init = { servletContext ->
        // add user
        UserWebservice.findByUsername('agus') ?: new UserWebservice(
                username: 'agus',
                password: 'ramdan').save(failOnError: true)

        //Register some wss4j security
        Map inProps = [:]
        inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
        // uncomment when need particular PASSWORD_TYPE
        //inProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_DIGEST);
        inProps.put WSHandlerConstants.PW_CALLBACK_REF, serverPasswordCallbackHandlerService

        annotatedSecureServiceFactory.getInInterceptors().add(new WSS4JInInterceptor(inProps))

        //These can be added here or taken care of in the @GrailsCxfEndpoint annotation
        //annotatedSecureServiceFactory.getProperties(true).put("ws-security.enable.nonce.cache","false")
        //annotatedSecureServiceFactory.getProperties(true).put("ws-security.enable.timestamp.cache","false")
    }
    def destroy = {
    }
}
Program selengkapnya bisa clone di git://git.cloudbees.com/agusramdan/SampleWSSecurity2.git

Minggu, 02 Juni 2013

Definition of Done Product Development RDV


Sebuah Product Development yang mengharapkan Continues Release haruslah mempunyai sebuah Definition of Done. Tanpa DoD akan meyebabkan kalimat template seperti dibawah ini akan muncul:

"Seharusnya melakukan ...... sebelum release"

Kalimat diatas adalah sebuah templet di mana titik-titik bisa di isi oleh aktifitas apa saja yang tidak dilakukan pada saat development.

Oleh karena itu untuk Product Development RDV ini mempunai DOD sebagai berikut

Definition of Done Team RDV

Semua UserStory harus:
- Unit telah di test dengan minimal Coverage 80% (Unit Tested)
- Source Code telah di commit pada Source Repository
- Integrasi telah di test dengan minimal Coverage 20% (Integration Tested)
- Dokumetasi deployment telah di tambahkan
- Secenario Acceptance Test telah telah selesai dibuat.

- Secenario Stress Test telah telah selesai dibuat.

Dengan mempunyai DoD yang jelas maka kita bisa menyatakan dengan percayadiri bahwa sebuah UserStory telah selesai.   DoD ini akan berkembang sesuai dengan waktu. Untuk saat ini di rasa DoD cukup menantang untuk dilaksanakan oleh team.

Senin, 13 Mei 2013

Couldfoudary

Akhir-akhir ini saya sangat tertarik dengan aplikasi yang di deploy pada cloud.  Setelah cari penyedia cloud yang gratis akhirnya saya menemukan cloudfoundry . Setelah di cobahternyata cukup nyaman juga. 

Setelah merenung beberapa malam akhirnya saya putuskan untuk membuat sebuah project open source mengunakan grails.  Project ini didedikasikan untuk developer team atau testing team agar mereka lebih terstruktur dalam pengerjaan project.

Project ini diberinama RDV singkatan dari "Requirement Development Verification".  Aplikasi ini harus dapat dijalankan di cloud.  Pada versi awal saya akan menggunakan Grails sebagai framework.  Semoga project ini bisa menjadi hiburan untuk perjalanan sebagai software developer.

Rabu, 03 Oktober 2012

Test Last VS Test First

Dalam sebuah tim Project Development saya sering melihat hahwa terjadi permushan antara kubu Programmer dan Tester.  Tester merasa banga bila menemukan bug dan Programmer merasa terhina bila hal tersebut terjadi.  Bila ditelaah lebih lanjut dan dilihat dari Software Development Life Cycle (SDLC) yang menggunakan waterfall.  Bila dilihat dari tahapan waterfall adalah sebagai berikut:


  1. Requirements specification
  2. Design
  3. Construction
  4. Validation (Testing and debugging)
  5. Maintenance

Dan bila kita melihat project plant bisanya seperti berikut.


Dengan menggunakan cara diatas maka bila terjadi fail pada saat verfiikasi akan menyebabkan project terlambat karena harus memperbaiki Bug.  Perbaikan bug ini bisanya cukup mejebalkan karena.  Programmer akan lebih stress bila mengerjakan perbaikan bug daripade coding baru hal inilah yang mengikatakan kemungkian lembur pada saat Validation. Untuk mengurahi efek stress bagi tim kami  coba menerapkan sedikit modifikasi dari project plan diatas menjadi sebagai berikut.


Pada strukur project plan yang baru aktifitas berhubungan dengan testing dialakukan beriringan dengan prosess task  yang dilakukan programmer. Yang menarik ada aktifias Test Script Construction. Aktifitas ini melakkan konversi dari scrip yang manual hasil dari Test Design menjadi Automatic Test, Computer Executed Manual Test. Computer Executed Manual Test adalah sebuah script yang di jalankan oleh aplikasi tertentu atau robot tapi yang mentukan bahwa test tesebut fail atau success adalah manusia. Model ini untuk menguragi labor work pada saat validation. Sehingga bisa lebih cepat dalam melakukan exekusi.

Automatic Test dan Computer Executed Manual Test script dapat digunakan oleh programmer untuk melakukan validasi atas pekerjanya pada fase konstruksi. Hal ini cukup menguntukan karena programmer dapat lebih awal mengetahui kesalahan programm sebelum benar-benar dilakukan fase berikutnya.  Gaya ini sedikit banyak dipengaruhi oleh Test-First dibandingkan Test-Last.

Keuntungan dari cara ini adalah Tester tidak akan bangga bila mekea menemukan bug pada saat verifikasi.  Hal tesebut dikarenakan Tester mepunyai andil terhadap hal tersebut. Dengan cara ini Tester dan Programmer dapat lebih solid karena mereka saling medukung untuk menghidari verifikasi yang gagal. Walaupun demikian labor work pada saat validation masih diperlukan karena ada beberapa hal.





Minggu, 30 September 2012

Nilai dari anggota tim

Sebuah diskusi singkat dalam ruang pengasapan kemarin sampai saat ini masih menjadi pemikiran saya.  Diskusi tersebut adalah bagaimana caranya agar kita dapat menilai anggota tim dengan fair. Dalam tim kami terbentuk menjadi dua kelopok sub tim yaitu Programmer dan Tester.
Saat itu saya ditantang untuk membuat sebuah sekema penilaian agar kedua kelopok ini dapat berkerja bersama agar men-deliver project yang dapat diterima oleh pengguna. Menurut opini saya skema tersebut haruslah menpunyai karakterisitik seperti berikut.
1. Mondorong untuk meningkatkan pencapaian pribadi.
2. Memberikan kontribusi maksimum pada tim.
3. Menghidari efek menjatuhkan panter (karana umunya Programmer dan Tester bermusuhan).
4. Menghidari untuk mencari kambing hitam (pointing finger).
5. Menjadi pembelajaran untuk fase project berikutnya.
Sampai tulisan ini di turunkan skema tersebut masih samar-samar.  Karena ada beberapa sekenario yang harus di uji sehingga dapat diterima dalam 5 buah karateristik diatas.

Selasa, 26 Juni 2012

Pengen koding di blog

Tadi siang saya lihat sebuah blog (http://codeformatter.blogspot.com/) yang dapat melakukan format koding. Akhirnya saya mencoba sedikit  programm Hello World.  Dan luar biasa ternyata bagus juga.

 package helloword;  
 public class HelloWord {  
   public static void main(String [] str) {  
     System.out.println("Hello World !!!");  
   }  
 }  

Setelah tau hal ini saya jadi lebih semangat untuk coding di blog.

Senin, 27 Juni 2011

Project Baru

Setelah tugas akademik kelar saya mulai berpikir untuk membuat sebuah aplikasi. Aplikasi ini sebenarnya sudah tertunda cukup lama tapi karana saya bingung harus mulai darimana akhirnya aplikasi tidak pernah di mulai. Memang langkah pertama itu sangat berat bisa diibaratkan bahwa langakah pertama itu bagai memindahkan gunung.

Oke mari kita bicarakan aplikasi yang akan dibuat. Sebelum bercerita banyak tentu harus jelas dulu apa tujuan dari proyek ini. Setelah berpikir beruang kali akhirnya saya simpulkan bahwa tujuan tersebut adalah tujuan pribadi dan tujuan aplikasi sendiri
Untuk tujuan pribadi adalah :
1. Mengingkatkan kemampuan untuk mencurahkan gagasan.
2. Mengingkatkan kemampuan menulis.
3. Mengingkatkan kemampuan merancang aplikasi.
4. Memperaktekan ilmu yang telah didapat

Sedangkan tujuan aplikasi adalah :
1. Dapat membantu transaksi yang melibatkan uang antara 2 orang yang belum saling kenal sehingga transaksi tersebut cukup aman tanpa melihat profile orang yang bertransaksi.
2. Dapat digabungkan dengan beberpa busines yang telah ada seperti pengririman barang, uang elektronik dan bank.

Saya kira cukup 2 buah tujuan aplikasi dan sekarang lakukan project baru ini.