Hình 2 .2-2 Kiến trúc phân tầng của Web Service
Hình 2.2-5 Web Service client sử dụng proxy
Một proxy là một lớp biểu diễn cùng giao diện và dấu hiệu phương thức như service nhưng thay vì thi hành trực tiếp hành vi được yêu cầu, nó gọi đến phương thức ở xa. Lớp proxy được tạo từ WSDL, nó được dịch và được làm cho sẵn sàng cục bộ như một phần của quá trình triển khai.
Các ứng dụng WebSphere MQ client có thể chạy một trong hai cơ sở hạ tầng SOAP cung cấp bởi .NET và Apache Axis1.1. Cả hai môi trường này đều cung cấp các công cụ để tạo các proxy từ WSDL.
2.2.2.2 Tầng SOAP [2, 5]
Cơ sở hạ tầng SOAP đang được sử dụng để thu thập các lời gọi hàm hoặc phương thức và định dạng các lời gọi này như một message theo định dạng XML để sẵn sàng cho việc truyền tải tới service. Khi message đã sẵn sàng, nó có thể được chuyển tới phần mềm truyền tải đã được đăng ký để quản lý URL cho Web Service.
Tại phía server (service), tầng SOAP mở gói message, xây dựng lại lời gọi và yêu cầu service, các giá trị trả về được xây dựng trong response message và SOAP truyền tải nó để chuyển trả lại.
Websphere MQ như một phương tiện truyền tải cho SOAP mà không xử lý hoặc cố gắng chuyển đổi dữ liệu SOAP. Vì vậy Websphere MQ hỗ trợ tương tác giữa các phần chỉ trong phạm vi thực thi SOAP có hỗ trợ.
URI cho một Web Service để được truy cập có sử dụng Websphere MQ theo sau cú pháp đã sử dụng cho SOAP/JMS luôn bắt đầu với “//jms:/queue?”. Phần còn lại của URI là một chuỗi các cặp tên-giá trị. Các cặp tên-giá trị cung cấp thông tin quyết định như:
- Destination: có thể là tên queue Websphere MQ hoặc tên queue và queue manager của request queue. Tham số này cung cấp một chuỗi cặp tên-giá trị chỉ ra chính xác cách Websphere MQ sender có thể kết nối tới Websphere MQ queue manager để đặt yêu cầu vào đó. Nó cung cấp chi tiết response queue tới bên trả lời thông điệp SOAP đã được định tuyến. Tuỳ chọn để cung cấp sự bảo mật cũng có thể đưa vào đây.
- ResponseQueue: Queue để trả lời từ một Web Service đã gửi
- InitialContextFactory: khi sử dụng định dạng jms URL, tham số này chỉ rõ trình cung cấp Java Naming and Directory Interface (JNDI) được sử dụng để tìm kiếm tham số connectionFactory.
- TargetService: tên của target service. Tầng SOAP phía server sử dụng tham số này để phân biệt các service đang chạy.
Ngoài ra còn các tham số cho phép các thuộc tính liên quan đến sự tồn tại và thời gian sống.
SOAP/WebSphere MQ sender[2, 5]
Một WebSphere MQ queue manager là một dịch vụ chứa các queue để các ứng dụng có thể lấy các message và có thể đọc sau đó bởi cùng một ứng dụng
hoặc các ứng dụng khác nhau. Queue manager có thể được cấu hình để định tuyến các message để đi từ ứng dụng gửi đến các queue trong queue manager ở xa. Trong trường hợp này, ứng dụng gửi là SOAP/WebSphere MQ sender. Ứng dụng đọc message là SOAP/WebSphere MQ listener kết hợp với Web Service.
Sender thực hiện các công việc sau khi tầng SOAP yêu cầu cùng với URI và thông điệp SOAP:
- Một cấu trúc header (WebSphere MQRFH2) được tạo và bổ sung trước dữ liệu thông điệp SOAP (SOAP message data), trong đó chứa dữ liệu biến đổi về thông điệp SOAP có thể được xử lý bởi SOAP/WebSphere MQ listener khi đi qua dữ liệu SOAP để tới phía service.
- Sender kết nối tới queue manager như mô tả trong tham số connectionFactory. Queue manager có thể là cục bộ hoặc ở xa so với sender và có thể có hoặc không chứa queue đích cho thông điệp SOAP.
- Một queue response, với chức năng nhận thông điệp trả lời từ service, được mở ra để nhận trả lời. Nếu queue này không có trong mô tả của URI thì sender sử dụng một queue mặc định.
Sender đặt message vào một queue trong queue manager. Nếu queue đích là queue local, WebSphere MQ kiểm tra nơi sender được phép ghi. Như một phần của thao tác put, một header khác là Message Descriptor được bổ sung vào message. Message Descriptor chứa thông tin về ứng dụng gửi, sự tồn tại và thời gian sống của message cũng như queue đích và queue manager. Thông tin về queue response cũng được đưa vào. Thông tin này được dùng để WebSphere MQ định tuyến message và cung cấp thông tin về sender đặt và yêu cầu message.
SOAP/WebSphere MQ listener[2, 5]
WebSphere MQ đưa các message được đặt bởi sender tới queue request, nơi SOAP/WebSphere MQ listener sẵn sàng nhận yêu cầu. Nếu SOAP/WebSphere MQ listener không sẵn sàng và listener triggering đã được cấu hình khi triển khai thì listener sẽ được bật lên khi có message đến.
Listener đọc message và thu được Message Dispatcher cùng WebSphere MQRFH2 header. Listener rút ra thông tin yêu cầu để định vị và yêu cầu Web Service sau đó đưa nó qua tầng SOAP.
2.2.2.3 Triển khai Service
Một trong những công việc quan trọng nhất để Web Service có hiệu lực là triển khai các server, các client proxy và các client. Thông thường việc này xảy ra sau khi service và ứng dụng client đã được viết. Các mã có thể thực thi, các proxy và WSDL thích hợp có thể được phân phối tới các vị trí và thư mục nơi cuối cùng chúng chạy. Việc thực thi SOAP dưới service đang chạy có thể được cấu hình để
đặt và chạy các phương thức của service khi chúng được yêu cầu và khi đó script sẽ bật các listener có thể cần đến.
Khi triển khai phải chắc chắn rằng cơ sở hạ tầng truyền thông cần thiết giữa client và server được cấu hình chính xác. Khi sử dụng Websphere MQ để truyền tải SOAP, việc triển khai cũng liên quan đến việc cấu hình Websphere MQ queue manager và client hoặc server connections cho chúng. Websphere MQ cũng bao gồm tiện ích triển khai được cài đặt như một phần của SOAP.
2.3. An toàn bảo mật thông tin qua SSL với Websphere MQ và Web Service Service
2.3.1. Vấn đề an toàn bảo mật thông tin qua SSL với Web service
Để đảm bảo an toàn cho đường đi của dữ liệu và có thể kiểm soát được liệu có ai đó thâm nhập vào thông tin trên đường truyền khi sử dụng web service, ta có thể kết hợp web service với SSL (Secure Socket Layer)[3] để thiết lập được một giao dịch an toàn.
SSL không phải là một giao thức đơn lẻ, mà là một tập các thủ tục đã được chuẩn hoá để thực hiện các nhiệm vụ bảo mật sau:
- Xác thực server: Cho phép người sử dụng xác thực được server muốn kết nối.
- Xác thực Client: Cho phép phía server xác thực được người sử dụng muốn kết nối.
- Mã hoá kết nối: Tất cả các thông tin trao đổi giữa client và server được mã hoá trên đường truyền nhằm nâng cao khả năng bảo mật.
Giao thức SSL bao gồm 2 giao thức con: giao thức SSL record[3] và giao thức SSL handshake[3]. Giao thức SSL record xác định các định dạng dùng để truyền dữ liệu. Giao thức SSL handshake (gọi là giao thức bắt tay) sẽ sử dụng giao thức SSL record để trao đổi một số thông tin giữa server và client vào lần đầu tiên thiết lập kết nối SSL.
Giao thức SSL hỗ trợ rất nhiều các thuật toán mã hoá, được sử dụng để thực hiện các công việc trong quá trình xác thực server và client, truyền tải các chứng thực số (certificates) và thiết lập các khoá của từng phiên giao dịch (sesion key).
2.3.2 SSL và Websphere MQ
Các message channel và Message Queue Interface (MQI) channel có thể sử dụng giao thức SSL để quy định sự an toàn bảo mật mức liên kết. Websphere MQ
hỗ trợ phiên bản 3.0 của giao thức SSL và phiên bản 1.0 của giao thức TLS (Transport Layer Security)[3]. Việc ánh xạ ý tưởng của một SSL client và SSL server vào các loại channel khác nhau đã cung cấp trong Websphere MQ là rất quan trọng. Với mỗi cặp channel, bộ khởi tạo giao tiếp được hướng đến SSL client trong khi đầu cuối của channel khác trở thành SSL server.
Việc chỉ ra các thuật toán mã hóa sử dụng cho giao thức SSL được cung cấp bởi thông số mã hóa và xác thực (CipherSpec)[3] như một phần của định nghĩa channel. CipherSpec là một hàm băm và thuật toán mã hoá đặc biệt. Các CipherSpec đều được chỉ ra trên nền per-channel và sử dụng một tham số trong định nghĩa channel gọi là SSLCipherSpec (SSLCIPH)[3]. Khi một channel an toàn đã được thiết lập, cả hai đầu phải có cùng CipherSpec. Tất cả các loại channel trong Websphere MQ đều có thuộc tính SSLCIPH. Đây cũng là thuộc tính nơi CipherSpec được thiết lập.
Encryption + Hash Function=CipherSpec (thông số mã hóa và xác thực)[3] CipherSpec + Authentication/Key Exchange=CipherSuite (bộ mật mã)[3] Để chỉ ra nơi channel đáp ứng sẵn sàng chấp nhận các kết nối, ta sử dụng tham số SSLClientAuthentication (SSLCAUTH) trong định nghĩa channel (có thể được đặt 1 trong 2 giá trị REQUIRED hoặc OPTIONAL)[3]. Trong quá trình SSL handshake, MCA (Message Channel Agent) gửi chứng thực số của Queue manager cho các cộng sự MCA của nó tại cuối các channel khác để xác thực. Tại client cuối của MQI channel, mã Websphere MQ client đảm nhiệm việc gửi chứng thực số, cùng với vai trò trình cung cấp dịch vụ an toàn bảo mật. Trong trường hợp này, mã Websphere MQ client đóng vai trò user của ứng dụng client. Các Queue manager và các user Websphere MQ client không cần các chứng thực số cá nhân kết hợp với chúng khi chúng đóng vai trò SSL client, trừ khi SSLCAUTH được chỉ rõ tại phía server của channel[3].
SSL có thể cho phép nhiều CipherSpecs được chuyển qua một client trong quá trình SSL handshake và server sẽ chọn một trong số những cái mà nó hỗ trợ. WebSphere MQ sẽ áp đặt hạn chế rằng chỉ một CipherSpec có thể được cung cấp trong định nghĩa channel và nó phải phù hợp với cả hai đầu[3].
Để sử dụng SSL cần phải có một giấy chứng thực cho mỗi bên khi muốn kết nối một cách an toàn. Đối với WebSphere MQ, điều này có nghĩa là cần một giấy chứng thực cho mỗi queue manager khi sử dụng MCA channel và mỗi giấy chứng thực cho một mã người sử dụng (user ID) truy cập vào hệ thống khi sử dụng MQI channel[3]. Các chứng thực số sẽ sử dụng trong WebSphere MQ được lưu trữ trong một key repository, được biết đến như một key database[3]. File repository có phần mở rộng là „.kdb‟. Tất cả các chứng thực, kể cả user và CA, đều được lưu trữ trong database này. Database được sử dụng bởi queue manager để quyết định
cái gì cho phép SSL bảo mật kết nối tới. Thuộc tính queue manager SSLKeyRepository[3] giữ vị trí của database trong file hệ thống không có phần mở rộng kdb, nó chỉ ra vị trí của repository giữ chứng thực số của queue manager. Các WebSphere MQ client cũng sử dụng SSLKeyRepository của chúng như một kho chứng thực số để quyết định queue manager server nào chúng tin cậy để giao tiếp một cách an toàn.
SSL được sử dụng trong Websphere MQ để xác thực từ Queue manager đến Queue manager và mã hóa mức liên kết, tức thông điệp được mã hóa khi chúng được chuyển qua mạng nhưng không được mã hóa khi lưu trữ trong queue. Nếu sự thiết lập chế độ an toàn đủ để bảo vệ các queue thì có thể chỉ cần yêu cầu thêm sự an toàn mức liên kết. Nếu hệ thống đã sẵn sàng xác thực các ứng dụng và mã hoá các message vào lúc MQPUT và giải mã chúng vào lúc MQGET thì các message đã được mã hoá ngay khi chúng còn lưu trữ trong queue, chúng có thể không cần mã hoá thêm khi được truyền qua mạng. Trong hoàn cảnh này, an toàn mức liên kết là không cần đến, hoặc chỉ cần đến cho xác thực queue manager đến queue manager ở mức nhỏ nhất.[3]
Để thiết đặt các message channel bảo mật và các MQI channel bảo mật có thể tiến hành qua các bước sau:
- Tạo key repository
- Tạo các chứng thực cho WebSphere MQ queue manager và client
- Bổ sung các chứng thực số vào key repository
- Chỉ rõ các thuộc tính SSL trong URI (Universal Resource Indicator) khi sử dụng WebSphere MQ truyền tải qua SOAP.
Cấu hình SSL cho WebSphere MQ truyền tải qua SOAP được cung cấp thông qua một số lựa chọn trong URI, các lựa chọn này phụ thuộc vào môi trường sử dụng chúng. Trong môi trường .NET, các lựa chọn sau được chỉ ra cho cấu hình SSL:
sslKeyRepository: Đây là lựa chọn chỉ ra vị trí của file SSL key repository (file .kdb)
sslCipherSpec: Lựa chọn này có thể nhận giá trị bất kỳ được chỉ ra trong giá trị SSLCIPH trong bất kỳ channel nào.
Công cụ được sử dụng để biểu thị key repository và quản lý chứng thực là IBM Global Kit (GSKit) được cung cấp cùng với bộ cài của WebSphere MQ.[3]
CHƢƠNG 3: XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN 3.1. Mô tả hoạt động nghiệp vụ
3.1.1 Một số khái niệm
- Hệ thống kết nối thanh toán giữa Ngân hàng và các CTCK: là hệ thống quản lý thông tin các CTCK và nhà đầu tư, có cơ sở dữ liệu tập trung đặt tại máy chủ Bank Gateway của Ngân hàng. Thông qua hệ thống, các CTCK có thể quản lý tiền gửi giao dịch chứng khoán của khách hàng và liên kết để kiểm tra điều kiện, thực hiện các giao dịch mua bán chứng khoán của khách hàng, thực hiện các giao dịch chuyển tiền ứng với nghiệp vụ chi trả cổ tức cho khách hàng…Đồng thời cả hai bên, CTCK và Ngân hàng, đều có thể giám sát và đối chiếu các giao dịch đã thực hiện thông qua các báo cáo đối chiếu của hệ thống.
- Hệ thống CoreBanking: Là hệ thống lõi của Ngân hàng, trong đó có phần quản lý các tài khoản tiền gửi của nhà đầu tư và CTCK, thực hiện các lệnh mở, đóng tài khoản tiền gửi, nộp, rút tiền thông qua giao diện của CoreBanking…và thực hiện các lệnh vấn tin, phong toả, giải phong toả, chuyển khoản…từ hệ thống kết nối thanh toán gửi đến.
- Tài khoản mua bán chứng khoán: Là tài khoản dùng để thực hiện giao dịch chứng khoán của nhà đầu tư mở tại CTCK.
- Tài khoản CA (Current Account): Là tài khoản tiền gửi tại Ngân hàng.
- Tài khoản TA (Trading Account): là tài khoản CA chuyên dùng của nhà đầu tư hoặc CTCK mở tại Ngân hàng dùng để giao dịch chứng khoán. Tài khoản TA có đầy đủ tính chất của một tài khoản tiền gửi không kỳ hạn tại Ngân hàng nên hoàn toàn có thể sử dụng các chức năng như gửi tiền, rút tiền (nếu số tiền rút hợp lệ), vấn tin tài khoản…thông qua hệ thống CoreBanking của Ngân hàng. - Thanh toán chứng khoán: Là giao dịch thanh toán giữa tài khoản tiền gửi thanh
toán của các CTCK và tài khoản Trading Account (TA) của nhà đầu tư chứng khoán tại Ngân hàng, được thực hiện với sự hỗ trợ của hệ thống kết nối thanh toán chứng khoán.
- Số dư khả dụng của tài khoản TA: Là số dư không bị phong toả của tài khoản (bằng số dư tài khoản trừ đi số tiền đang bị phong toả) mà chủ tài khoản có thể dùng để thực hiện các giao dịch như rút tiền, mua chứng khoán, chuyển tiền…
3.1.2 Mô tả nghiệp vụ:
Mỗi CTCK có liên kết với Ngân hàng để thực hiện thanh toán chứng khoán sẽ có hai tài khoản tiền gửi tại một chi nhánh nào đó của Ngân hàng:
- Một tài khoản CA dùng để quản lý và hạch toán các giao dịch mua/bán chứng khoán của các Nhà đầu tư tại CTCK.
- Một tài khoản TA dùng để quản lý và hạch toán các giao dịch mua/bán chứng khoán của CTCK trong hoạt động kinh doanh và các giao dịch liên quan khác của chính CTCK (Tài khoản tự doanh).
Tài khoản thứ nhất sẽ được sẽ được khai báo cùng với thông tin về CTCK trên hệ thống kết nối thanh toán, tài khoản thứ hai cũng sẽ được khai báo nhưng với tính chất như tài khoản của nhà đầu tư thông thường.
Vì Ngân hàng sẽ quản lý tiền đầu tư chứng khoán của các nhà đầu tư nên mỗi nhà đầu tư phải được mở một tài khoản tiền gửi tại một chi nhánh nào đó của ngân hàng. Tài khoản này cũng là tài khoản Trading Account và sẽ được gắn kết với tài khoản hoạt động chứng khoán của nhà đầu tư tại CTCK thông qua hệ thống kết nối thanh toán.