Single Sign On (SSO)-SAML

S

Single Sign On (SSO) – SAML
(Đăng nhập một lần)

I) Single Sign On:

– Là một thuật ngữ của việc kiểm soát truy cập nhiều hệ thống liên quan. Với việc sử dụng thuật ngữ này cho phép người dùng đăng nhập với một ID và mật khẩu duy nhất để có thể truy cập vào một hệ thống hay nhiều hệ thống kết nối với nhau mà không cần sử dụng nhiều tên đăng nhập và mật khẩu khác nhau của từng hệ thống.
– Khi người dùng đăng nhập vào một hệ thống, họ sẽ đăng nhập vào tất cả các hệ thống khác liên quan.
– VD: Google sử dụng cho những sản phẩm của họ như: Gmail, YouTube, Google Maps… khi ta đăng nhập vào 1 app tất cả các app còn lại cũng được đăng nhập.
– Ưu điểm :
+ Thuận tiện: Người sử dụng chỉ cần đăng nhập 1 lần để sử dụng nhiều ứng dụng.
+ Bảo mật: Bởi vì chỉ có một đăng nhập một lần, SSO có thể loại bỏ những rủi ro vốn có trong việc ghi nhớ nhiều username/password.
– Nhược điểm :
+ Bảo mật: Nếu một kẻ xâm nhập làm tổn hại tài khoản của người dùng hoặc mật khẩu, kẻ xâm nhập có thể có rộng rãi và dễ dàng truy cập vào rất nhiều ứng dụng.
+ Chi phí: triển khai SSO có thể tốn kém, cả về chi phí để mua và nguồn nhân lực để triển khai. Hai yếu tố SSO là tốt nhất, nơi truy cập được cấp dựa trên sự kết hợp đối với những gì người sử dụng biết (mật khẩu hoặc mã PIN)

SAML

– Là một “chuẩn mở” cho phép nhà cung cấp thực thể (Identity Provider – IdP) xác thực người dùng và ủy quyền cho người dùng sử dụng một dịch vụ nào đó của nhà cung cấp dịch vụ (Service Provider – SP) mà không bắt buộc người dùng phải tạo tài khoản đăng nhập vào dịch vụ đó.
– Các dịch vụ SSO dựa trên SAML bao gồm giao tiếp giữa người dùng, nhà cung cấp nhận dạng và nhà cung cấp dịch vụ. Một khi thông tin đăng nhập của người dùng được cung cấp, xác thực sẽ được ban hành cho các ứng dụng khác mà người dùng muốn truy cập và không yêu cầu người dùng nhập lại thông tin đăng nhập.
– Cách hoạt động của SAML: 

+ SP là nhà cung cấp dịch vụ (là ứng dụng cần đăng nhập), IdP là nhà cung cấp các thực thể (tài khoản người dùng – IdP ở đây là ứng dụng cần đăng nhập).

  • Bước 1: User sẽ click vào nút “Đăng nhập bằng tài khoản của cái gì đó” từ browser, request này sẽ được gửi tới SP.
  • Bước 2: Phía SP sẽ tạo ra một SAML Request để gửi tới IdP, SAML Request này sẽ được chính SP ký điện tử (sign) bằng chữ ký của SP (chữ ký của SP ở đây chính là khóa bí mật của SP). 
  • Bước 3: Phía IdP khi nhận được SAML Request từ SP sẽ phải xác thực chữ ký có đúng là của SP hay không bằng cách dùng khóa công khai của SP để xác thực:

+ Trước khi thực hiện giao dịch, SPIdP phải bằng cách nào đó trao đổi được khóa công khai với nhau trước (không phải khóa bí  mật nhé). Thông thường, mỗi bên SPIdP sẽ có một public url chứa metadata, metadata này chứa các thông tin công khai như là khóa công khai, ID thực thể và URL để điều hướng khi có request đến. Phía IdP sẽ biết được metadata url của SP để từ đó lấy ra khóa công khai của SP để xác thực chữ ký của SP. Trong trường hợp hệ thống của Idp đã có sẵn và không lấy public key của SP thông qua metadata url được thì SP phải gửi khóa công khai của mình cho Idp cài đặt trước khi thực hiện giao dịch.

  • Bước 4: Vẫn đang ở IdP, sau khi xác thực được chữ ký của SP rồi, IdP sẽ làm những thứ sau:
    • Lấy ra thông tin người dùng đang sử dụng browser (nếu người dùng đang đăng nhập vào IdP, còn nếu người dùng đang không đăng nhập thì bắt người dùng đăng nhập trước) để redirect (http post) về cho SP sử dụng (kết quả trả về này mình gọi là SAML Response). Trước khi gửi về cho SP thì IdP sẽ ký điện tử (sign) vào SAML Response bằng khóa bí mật của IdP.
    • Không những IdP ký vào SAML Response IdP cũng sẽ mã hóa các kết quả dữ liệu (SAML Assertions) có trong SAML Response bằng khóa công khai của SP.
  • Bước 5: Khi SP nhận được SAML Response, nó sẽ thực hiện những việc sau:
    • Dùng khóa công khai của IdP để xác thực xem có đúng là kết quả được gửi từ IdP hay không (đây chính là phần xác thựcOAuthOAuth2 không có). Khóa công khai của IdP cũng giống như nói ở trên, có thể lấy thông qua metadata url của IdP hoặc có thể được trao đổi trước.
    • Nếu xác thực đúng chữ ký, SP sẽ tiếp tục dùng khóa công khai của chính mình để giải mãi SAML Assertions đã được mã hóa từ phía IdP.
    • Lấy các thông tin dữ liệu người dùng trong SAML Assertions để đăng nhập người dùng vào hệ thống của chính mình, và trả về cho người dùng thông báo thành công (hay điều hướng người dùng tới các tài nguyên mong muốn).

 

II) Tích hợp với Linework

– Ở bài viết này chúng ta dùng Laravel Framework (version 5.8) và thư viện Laravel-SAML2 (Github)

  1. Cài đặt

– Để cài đặt, ta dùng câu lệnh:
composer create-project –prefer-dist laravel/laravel blog “5.8”
– Tiếp theo để install thư viện Laravel-Saml2 ta dùng lệnh:
composer require aacotroneo/laravel-saml2

hoặc trong composer.js ta thêm câu  lệnh sau vào vào require và run composer install
“aacotroneo/laravel-saml2”: “*”

  1. Config

– Nếu bạn đang sử dụng Laravel 5.5 hoặc mới hơn package tự động được đăng kí Service Provider
– Đối với các phiên bản cũ hơn của Laravel, chúng ta phải đăng kí Service Provider trong config/app.php

‘providers’ => [
        
     Aacotroneo\Saml2\Saml2ServiceProvider::class,
]
– Tiếp theo chúng ta publish config của package với command:
php artisan vendor:publish –provider=”Aacotroneo\Saml2\Saml2ServiceProvider”

 


Sau khi command trên được chạy, nó sẽ thêm file
app/config/saml2_settings.php app/config/saml2/test_idp_settings.php
– Tại file smail2_settings.php nó sẽ khai báo các route login, logout… và controller (có thể config theo ý mình)

 

 

– Chúng ta quan tâm đến file test_idp_settings.php
– Tại file này chúng ta cần config theo idP của Lineworks

– Để lấy được các thông tin của idP chúng ta vào LineWorks Console để đăng kí thông tin SP (Service Provider)


– Tại đây, chúng ta cần điền vào các thông tin cơ bản như sau (Tham khảo
tại đây):
+ Application Name: Tên ứng dụng bạn đăng kí sử dụng (tên tùy ý)
+ Description: Mô tả ứng dụng (không bắt buộc)
+ Logo: Ảnh ứng dụng
+ ACS URL: http://127.0.0.1:8000/saml2/lineworks/acs (ex: http://laravel_url/myidp1/acs)
+ SP Issuer(Entity Id): http://127.0.0.1:8000/saml2/lineworks/metadata (ex:http://laravel_url/myidp1/metadata)
– 2 Tham số ACS URL và SP Issuer cần thay đổi khi deploy app
– Sau khi đăng kí thông tin SP thành công, chúng ta cần kích hoạt SP rồi tiếp tục config apps trong app/config/saml2/test_idp_settings.php
+ $this_idp_env_id: value idP => lineworks
+ NameIDFormat: urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
(Xem thêm)

+ EntityId: Response Issuer idP ở SP vừa tạo
+ singleSignOnService->url: SSO URL của idP
+ singleLogoutService->url: Lineworks không hỗ trợ lên tôi không điền
+ X509cert: ở bước đăng kí SP, trong mục LINE WORKS Identity Provider -> Certificate ta down file Certificate về sẽ được file xxxx.pem, mở file bằng editor bất kì ta sẽ lấy được Certificate
– Hoàn thành bước config cho package Laravel-SAML2
– Tạo Middleware cho saml2 băng command: php artisan make:middleware Saml2
– Mở file vừa tạo tại app/Http/Middleware/Saml2.php trong func handle có nội dung như sau:


– Khai báo Middleware trong Kernel (app\Http)

– Tại middleware này, nó sẽ check User đã login hay chưa mà cho phép request tiếp theo, nếu chưa login sẽ được chuyển hướng đến trang login idP tương ứng.
– Sau khi Login được gọi, người dùng sẽ được chuyển hướng đến trang login của idP, Sau đo idP mà chúng ta đã config ở trên sẽ call back /myidp1/acs or /routesPrefix/myidp1/acs và phát ra 1 Event, bước tiếp theo là chúng ta lắng nghe và xử lý sự kiện đó
– Trong file EventServiceProvider (app\Provider) ta khai báo sự kiện:


và chạy command: php artisan event:generate
– Sau khi chạy command trên, nó sẽ generate ra file SAML2LoginListener (app\Listeners)
– Tại đây ta cần use Aacotroneo\Saml2\Events\Saml2LoginEvent;
– code handle:

public function handle(Saml2LoginEvent $event)
{
        $messageId = $event->getSaml2Auth()->getLastMessageId();
            // Add your own code preventing reuse of a $messageId to stop replay attacks
        $user = $event->getSaml2User();
        $userData = [
            ‘id’ => $user->getUserId(),
            ‘attributes’ => $user->getAttributes(),
            ‘assertion’ => $user->getRawSamlAssertion()
        ];
        //data result from idP
        dd($userData);
    }

– Tiếp theo tạo route để test (routes\web.php)

  1. TEST

– Chạy server và test (commad run server: php artisan serve) theo path: /login

Dữ liệu trả về

 

 

 

 

 

 

Tagcloud

Posts