Monday, February 17, 2020

Tham khảo từ:
https://viblo.asia/p/nhung-kien-thuc-co-ban-nhat-ma-bat-cu-lap-trinh-vien-nao-cung-phai-biet-ve-encoding-va-character-set-phan-1-bJzKmgxOl9N

Những kiến thức cơ bản nhất mà bất cứ lập trình viên nào cũng phải biết về Encoding và Character Set (Phần 1)

Làm rõ các khái niệm cơ bản

Chắc rằng tất cả mọi người đều biết về điều này ở một mức độ nào đó, nhưng không hiểu sao những kiến thức đó lại bị mất đi trong các cuộc tranh luận về văn bản, nên đầu tiên hãy nhắc lại một chút: Máy tính không thể nào lưu trữ được “chữ”, “số”, “ảnh”, hay bất cứ thứ gì khác. Thứ duy nhất mà nó có thể lưu được và làm việc cùng đó là bit. Một bit chỉ có thể có 2 giá trị: có hoặc không, đúng hoặc sai, 1 hoặc 0, bạn thích gọi theo cách nào cũng được. Vì máy tính hoạt động bằng điện, một bit thực chất có thể được thể hiện bằng điện áp, xung hiện tại hoặc trạng thái điện của mạch flip-flop. Đối với con người, bit thường được biểu thị bằng 1 và 0 nên hãy coi đây là quy ước trong suốt bài viết này.
Để dùng bit để thể hiện cho bất cứ thứ gì, chúng ta cần các quy tắc. Chúng ta cần phải chuyển đổi một chuỗi các bit thành thứ gì đó như chữ, số và ảnh bằng cách sử dụng một encoding scheme (lược đồ mã hóa), hoặc gọi tắt là encoding. Như thế này:
01100010 01101001 01110100 01110011
b        i        t        s
Trong encoding này, 01100010 đại diện cho chữ "b", 01101001 cho chữ "i", 01110100 cho chữ "t" và 01110011 cho chữ "s". Một chuỗi các bit nhất định sẽ đại diện cho một chữ và một chữ sẽ đại diện cho một chuỗi các bit nhất định. Nếu bạn có trí nhớ tốt để nhớ được chuỗi bit cho 26 chữ thì bạn có thể đọc bit như đọc sách vậy.
Encoding scheme trên được gọi là ASCII. Một chuỗi các số 1 và 0 được chia ra thành nhiều phần, mỗi phần 8 bit (hoặc 1 byte). ASCII quy định một bảng để dịch từ byte sang chữ cái mà con người có thể đọc được. Dưới đây là một phần nhỏ của bảng đó:
bits character
01000001 A
01000010 B
01000011 C
01000100 D
01000101 E
01000110 F
Có tổng cộng 95 ký tự có thể đọc được quy định trong bảng ASCII, bao gồm chữ từ A đến Z ở trạng thái thường và in hoa, số từ 0 đến 9, một số dấu chấm câu và các ký tự như đồng đô la, dấu chấm than và một vài thứ khác. Nó cũng bao gồm 33 giá trị cho một số thứ như dấu cách, dấu xuống dòng, tab, backspace,... Những thứ này tất nhiên không thể in ra được, nhưng cũng vẫn hữu hình ở một số dạng và có ích trực tiếp với con người. Một vài giá trị thì chỉ có ích với máy tính, như mã để đánh dấu bắt đầu và kết thúc của văn bản. Tộng cộng có 128 ký tự được định nghĩa trong encoding ASCII, đó là một con số đẹp (với những người quen thuộc với máy tính), bởi vì nó sử dụng hết tất cả các kết hợp có thể của 7 bit (0000000 cho đến 1111111).
Và giờ thì chúng ta đã có cách để thể hiện văn bản chỉ bằng việc sử dụng 1 và 0:
01001000 01100101 01101100 01101100 01101111 00100000
  01010111 01101111 01110010 01101100 01100100
  
"Hello World"

Thuật ngữ quan trọng

Để encode một thứ gì đó bằng ASCII, làm theo bảng từ phải qua trái, thay thế các chữ bằng các bit. Để decode một chuỗi các bit thành các ký tự có thể đọc được, làm theo bảng từ trái qua phải, thay thế các bit bằng chữ.
Encode nghĩa là sử dụng một thứ gì đó để thể hiện cho một thứ khác. encoding là một tập hợp các quy tắc để thực hiện việc chuyển đổi đó.
Một số thuật ngữ khác cần được làm rõ trong ngữ cảnh này:
character set, charset
Tập hợp các ký tự có thể được encode. "Mã hóa ASCII bao gồm một bộ ký tự gồm 128 ký tự." Về cơ bản thì đồng nghĩa với "encoding".
code page
Một "trang" các mã để liên kết các ký tự với một chuỗi các bit tương ứng. Cũng có thể hiểu là một "bảng". Về cơ bản thì đồng nghĩa với "encoding".
string
Một string là một số các thành phần được xâu lại với nhau. Một chuỗi bit là một loạt các bit, như 01010011. Một chuỗi ký tự là một loạt các ký tự, như thế này. Đồng nghĩa với "sequence".
Binary, Octal, Decimal, Hex
Có rất nhiều cách để viết một số. 10011111 trong hệ nhị phân là 237 trong hệ bát phân, 159 trong hệ thập phân và 9F trong hệ thập lục phân. Chúng đều thể hiện một giá trị, nhưng số thập lục phân lại ngắn gọn hơn và dễ đọc hơn so với số nhị phân. Tuy vậy tôi sẽ dùng nhị phân trong suốt bài viết này để làm vấn đề trở nên dễ hiểu hơn cũng như loại bỏ bớt được một lớp trừu tượng. Đừng lo nếu bạn thấy ở đâu đó các mã ký tự lại được viết ở hệ khác nhé, chúng như nhau cả thôi.

Excusez-Moi?

Sau khi đã nắm rõ những ý trên rồi thì cùng thú thật với nhau nào: 95 ký tự là quá ít khi chúng ta nói về các ngôn ngữ. Nó có thể áp dụng cho tiếng Anh cơ bản, nhưng sẽ thế nào nếu chúng ta muốn viết một risqué letter (thư báo rủi ro) bằng tiếng Pháp? Straßen­übergangs­änderungs­gesetz (luật đường bộ) trong tiếng Đức? Một lời mời đến tiệc smörgåsbord (tiệc đứng) bằng tiếng Thụy Điển? Ờm, bạn không thể. Không thể bằng ASCII. Không có một chỉ dẫn nào cho việc thể hiện các chữ như é, ß, ü, ä, ö or å trong ASCII, nên chúng ta không thể dùng nó được.
"Nhưng nhìn xem," dân châu Âu nói, "trong một cái máy tính thông dụng với 1 byte bằng 8 bit, mã hóa ASCII đang làm phí phạm hẳn 1 bit khi luôn set giá trị của nó là 0! Chúng ta có thể dùng bit này để nhét thêm tận 128 giá trị vào cái bảng đó!" Và họ đã làm như vậy. Nhưng kể cả thế, có nhiều hơn 128 cách để đặt dấu cho một nguyên âm. Chúng ta không thể nào đưa hết tất cả các biến thể của chữ cái được dùng trong các ngôn ngữ của toàn Châu Âu vào trong cùng một bảng với tối đa 256 giá trị được. Và sau đó thế giới chìm ngập trong một biển các encoding, các tiêu chuẩn, các tiêu chuẩn thực tế và thậm chí là... nửa tiêu chuẩn để dùng cho các bộ ký tự khác nhau. Một người nào đó cần phải viết một văn bản về tiếng Thụy Điển bằng tiếng Séc, tìm không ra encoding nào áp dụng cho cả 2 ngôn ngữ này nên đành tự chế ra một cái. Và chuyện đó diễn ra hàng ngàn lần.
Và cũng đừng quên tiếng Nga, tiếng Ấn Độ, tiếng Ả Rập, tiếng Do Thái, tiếng Hàn và hàng ngàn ngôn ngữ khác đang được dùng trên trái đất. Chưa kể các ngôn ngữ đã không còn được dùng nữa. Một khi bạn đã giải được bài toán làm thế nào để viết nhiều ngôn ngữ trong cùng một văn bản với các thứ tiếng trên, hãy thử thách bản thân bằng tiếng Trung. Hoặc tiếng Nhật. Cả 2 ngôn ngữ này chứa cả chục nghìn ký tự. Bạn có tối đa 256 giá trị trong một byte chứa 8 bit. Triển!

Mã hóa đa byte (Multi-Byte Encodings)

Để tạo ra một bảng liên kết các ký tự với chữ cái cho một ngôn ngữ có nhiều hơn 256 ký tự, một byte đơn giản là không đủ. Với 2 byte (16 bit), chúng ta có thể mã hóa tới 65,536 ký tự khác nhau. BIG-5 là một encoding sử dụng cách đó. Thay vì tách một chuỗi các bit thành block 8, nó tách thành block 16 và có một cái bảng khổng lồ (ý tôi là, KHỔNG LỒ) quy định việc ký tự nào thì liên kết cùng chuỗi bit nào. BIG-5 ở thể đơn giản nhất đã xử lý hầu hết các ký tự của tiếng Trung phồn thể. GB18030 là một encoding khác cũng có cách tiếp cận tương tự, nhưng nó bao gồm cả tiếng Trung giản thể và phồn thể luôn. Và trước khi bạn hỏi, thì đúng vậy, có cả các encoding khác chỉ dành cho tiếng Trung giản thể thôi. Tôi chỉ muốn dùng 1 encoding thôi mà cũng khó khăn thế sao?
Dưới đây là một phần nhỏ của bảng mã hóa GB18030:
bits character
10000001 01000000
10000001 01000001
10000001 01000010
10000001 01000011
10000001 01000100
GB18030 xử lý một lượng lớn các ký tự (bao gồm cả phần lớn các ký tự La tinh), tuy nhiên cuối cùng thì nó cũng chỉ là một định dạng mã hóa chuyên biệt trong hàng hà sa số các cái khác thôi.

Sự bối rối mang tên Unicode

Cuối cùng thì cũng có người chịu hết nổi và đã đứng lên tạo ra một chuẩn mã hóa để hợp nhất tất cả các chuẩn khác. Chuẩn này được gọi là Unicode. Về cơ bản nó định nghĩa một bảng lớn cực đại với 1,114,112 các code point có thể được dùng cho mọi loại chữ cái và biểu tượng. Nó thừa đủ để mã hóa toàn bộ tiếng châu Âu, Trung Đông, Viễn Đông, miền Nam, miền Bắc, miền Tây, tiền sử và cả các ngôn ngữ tương lai mà con người chưa nghĩ ra. Sử dụng Unicode, bạn có thể soạn văn bản chứa gần như mọi ngôn ngữ bằng mọi ký tự mà bạn có thể gõ ra. Điều này hoặc là bất khả thi hoặc rất rất khó để thực hiện trước khi Unicode ra đời. Thậm chí còn có một mục không chính thức dành cho tiếng Klingon (Star Trek) trong Unicode. Bạn thấy đó, Unicode lớn đến nỗi nó cũng cho phép dùng vào mục đích cá nhân luôn.

Vậy thì Unicode sử dụng bao nhiêu bit để mã hóa tất cả các ký tự đó? 0. Bởi vì Unicode không phải một loại mã hóa (encoding).
Bối rối? Nhiều người có vẻ như vậy. Đầu tiên, Unicode định nghĩa ra một bảng chứa các code point cho các ký tự. Nghe có vẻ nguy hiểm vậy thôi, nó cũng như là nói "65 đại diện cho A, 66 cho B và 9,731 cho ☃" (thật đấy). Làm thế nào mà những code point này được mã hóa thành bit thì lại là một câu chuyện khác. Để chứa 1,114,112 giá trị khác nhau, 2 byte là không đủ. 3 byte thì đủ, nhưng chả ai dùng 3 byte cả, nên cuối cùng 4 byte đã được chọn. Nhưng, trừ khi bạn dùng tiếng Trung hoặc các thứ tiếng khác với một lượng lớn các ký tự mà cần nhiều bit để mã hóa, bạn sẽ chẳng bao giờ dùng hết phần lớn 4 byte đó cả. Nếu chữ "A" luôn được mã hóa thành 00000000 00000000 00000000 01000001, "B" thì thành 00000000 00000000 00000000 01000010,.. mọi văn bản sẽ có kích thước tăng lên 4 lần so với kích thước thực.
Để tối ưu hóa vấn đề này, có rất nhiều cách để mã hóa code point thành bit. UTF-32 là một encoding có tác dụng mã hóa mọi code point sử dụng 32 bit. Nghĩa là, 4 byte trên một ký tự. Nó rất đơn giản, nhưng thường thì chiếm kích thước quá lớn. UTF-16 và UTF-8 là 2 loại mã hóa đa chiều dài. Nếu một ký tự có thể được mã hóa bằng 1 byte (bởi vì code point của nó là một số rất nhỏ), UTF-8 sẽ mã hóa nó bằng 1 byte. Nếu ký tự cần tới 2 byte, nó sẽ mã hóa bằng 2 byte, vân vân. Khi giải mã (decode), byte đầu tiên trong chuỗi sẽ được sử dụng để xác định số byte cấu tạo thành ký tự, cụ thể:
  • Chuỗi bắt đầu bằng mẫu bit "0" (0x00-0x7f) => chuỗi dài 1 byte.
  • Chuỗi bắt đầu bằng mẫu bit "110" (0xc0-0xdf) => chuỗi dài 2 byte.
  • Chuỗi bắt đầu bằng mẫu bit "1110" (0xe0-0xef) => chuỗi dài 3 byte.
  • Chuỗi bắt đầu bằng mẫu bit "11110" (0xf0-0xf7) => chuỗi dài 4 byte.
Việc sử dụng bit có trọng số cao nhất (MSB) làm tín hiệu thông báo độ dài chuỗi có thể giúp giảm hao tốn bộ nhớ, nhưng vẫn sẽ tốn kém nếu được dùng quá thường xuyên. UTF-16 thì cân bằng hơn, dùng ít nhất 2 byte, sẽ tăng lên đến 4 byte nếu cần.

Và đó là tất cả về Unicode. Unicode là một bảng lớn với mục đích liên kết các ký tự với các số và các loại mã hoá UTF khác nhau thì chỉ định cách thức mà những số này được mã hoá thành bit. Về cơ bản, Unicode cũng chỉ là một trong các encoding scheme và không có gì đặc biệt về nó ngoại trừ việc nó cố gắng để xử lý mọi thứ trong khi vẫn hoạt động một cách hiệu quả mà thôi. Và đó là một điều rất tốt.™

Code Points

Các ký tự được thể hiện thông qua "code point" của nó. Code point được viết dưới hệ thập lục phân (để làm cho nó ngắn hơn), được bắt đầu bằng "U+" (không có ý nghĩa gì ngoài việc ám chỉ đây là một code point của Unicode). Ví dụ, ký tự Ḁ có code point là U+1E00. Theo cách nói khác, nó là ký tự số 7680 của bảng Unicode. Tên gọi chính thức của nó là "LATIN CAPITAL LETTER A WITH RING BELOW" (Chữ la tinh viết hoa A với vòng tròn ở dưới).

Dài quá, ngại đọc

Một chút tóm tắt các ý trên: Mọi ký tự có thể được mã hoá thành nhiều chuỗi bit khác nhau và bất chứ chuỗi bit nào cũng có thể thể hiện các ký tự khác nhau, tuỳ thuộc vào loại mã hoá nào được dùng để viết chúng ra. Lí do đơn giản chỉ vì các mã hoá khác nhau thì sử dụng số bit khác nhau với mỗi ký tự và các giá trị khác nhau thì thể hiện các ký tự khác nhau.

(Hết phần 1)
Bài viết được dịch từ What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text.
Có tham khảo và chỉnh sửa thêm từ các nguồn:

Thursday, February 6, 2020

Namespace


https://techterms.com/definition/namespace

A namespace is a group of related elements that each have a unique name or identifier. There are several different types of namespaces, and each one has a specific syntax used to define the corresponding elements. Each element within a namespace has a "local name" that serves as a unique identifier.
Namespaces are used in many areas of computing, such as domain names, file paths, and XML documents. Below are examples of these different applications.
  1. Domain Names - The namespace syntax for domain names is specified by the Domain Name System, or DNS. It includes the top-level domain, (e.g. "techterms.com") and a subdomain, such as "www." In the URL "www.techterms.com," the namespace identifier is "techterms.com," while the local name is "www."
  2. File Paths - File locations may be specified using a file path, which can include multiple directories. A file path, which uses syntax defined by the operating system, is considered a namespace. For example, C:\Program Files\Internet Explorer is the namespace that describes where Internet Explorer files on a Windows computer. The namespace /usr/local/apache/ defines the location of Apache files on a Unix-based web server. Individual filenames within these directories serve as unique identifiers.
  3. XML Documents - XML namespaces (XMLNS) are used to associate a document's element and attribute names with a namespace identified by an external URI. For example, an XML file may include HTML elements that are specified at "http://www.w3.org/1999/xhtml." This reference might appear as "<html:html xmlns:html='http://www.w3.org/1999/xhtml'>" near the top of the XML document.
The above examples are just a few types of namespaces used in computing. They are also used to define network devices and other types of computer hardware. Additionally, computer programmers often used namespaces to group related variables within the source code of a program. While there are many different types of namespaces, they all serve the same purpose — to contain a logical grouping of related elements.

Thursday, May 12, 2016

Tìm hiểu Single Sign On



    1.1. Single Sign On.
    1.1.1. Khái niệm.
    SSO còn được gọi là ESSO cho phép nhập cùng một id/password để đăng nhập
    nhiều ứng dụng trong cùng một tổ chức (Enterprise).
    Ví dụ:
    Người dùng sử dụng nhiều dịch vụ như: Đăng ký môn học, hê thống xem điểm, … ứng mỗi dịch vụ chúng ta có một tài khoản riêng. Trước đây, khi chưa sử dụng SSO thì khi với mỗi dịch vụ chúng ta đều phải nhập thông tin để xác thực. Khi một tổ chức đã thống nhất sử dụng SSO cho tất cả các dịch vụ của họ thì người dùng chỉ cần đăng nhập một lần duy nhất trên bất kỳ dịch vụ nào trong tổ chức, thì khi truy xuất những dịch vụ khác, người dùng không cần phải đăng nhập lại.

    1.1.2. Lợi ích.
    - Tránh việc nhớ nhiều thông tin đăng nhập (username & password) khi dùng nhiều dịch vụ.
    - Tiết kiệm thời gian khi tái lập lại mật khẩu cho một người dùng (identity user).
    - Bảo mật tất cả các cấp độ của việc thoát hay truy xuất vào hệ thống.
    - Người phát triển ứng dụng không cần phải hiểu và thực hiện nhận dạng bảo mật trong ứng dụng của họ.

    1.1.3 Các giải pháp Single Sign On.
    - Open Single Sign-On (OpenSSO) hoạt đông dựa trên Token.
    - Central Authenticate Service (CAS) hoạt đông dựa trên Ticket.
    - JOSSO (Java Open Sigle Sign On), CoSign,…
    Nguồn: 
    http://xacthucsso.blogspot.com/2013/07/tim-hieu-single-sign-on.html

Ứng dụng hệ thống kiểm soát truy nhập mạng theo mô hình truy nhập một lần

Bài báo giới thiệu Hệ thống xác thực truy nhập một lần (SSO), so sánh phân tích và đánh giá các giải pháp SSO, đồng thời trình bày kết quả nghiên cứu triển khai ứng dụng theo mô hình CAS.
1. Giải pháp kiểm soát truy nhập hệ thống SSO
Hiện nay, ứng dụng chạy trên các máy chủ lớn dần được thay thế bằng các ứng dụng mạng phân tán khách - chủ (client - server) thông qua một lượng lớn các hệ thống nhỏ chạy trên các hạ tầng độc lập với số lượng người dùng và hệ thống cần quản trị tăng lên nhanh chóng.
Mỗi lần truy nhập một dịch vụ của hệ thống, người dùng phải khai báo thông tin về mật khẩu và tên đăng nhập cho hệ thống xác thực. Do vậy, người dùng phải nhớ rất nhiều cặp tên truy cập/mật khẩu khác nhau và phải đăng nhập nhiều lần. Điều này gây khó khăn cho người dùng và nhà cung cấp dịch vụ, người quản trị cũng phải đối mặt với một loạt vấn đề như bảo mật, mã hóa, lưu trữ cơ sở dữ liệu. 
Trước đây, để giải quyết vấn đề này, người sử dụng bắt buộc phải nhớ các thông tin đăng nhập, hoặc lưu trong các file có mã hóa, hoặc sử dụng một chương trình quản lý tài khoản trên máy tính của họ. Tuy nhiên, người dùng vẫn phải nhớ quá nhiều tên truy cập/mật khẩu, người quản trị luôn nhận được các yêu cầu tạo lại mật khẩu và kích hoạt lại tài khoản người dùng, do họ gặp phải các sự cố về thông tin đăng nhập. 
Một giải pháp cho vấn đề trên là sử dụng một kỹ thuật xác thực một lần cho tất cả các tài khoản có yêu cầu bảo mật khác nhau. 
Giải pháp này vừa đảm bảo tính thuận tiện, vừa tăng độ bảo mật khi sử dụng. Hơn nữa, áp lực trong việc quản lý tài khoản đối với nhà quản trị hệ thống có thể được giảm xuống. Hệ thống SSO có khả năng tích hợp và kết hợp các hệ thống tài khoản khác nhau. Điều này sẽ đem lại lợi ích cả cho người dùng và nhà cung cấp dịch vụ. 
Ưu điểm của giải pháp SSO
Đối với người dùng: Hệ thống SSO cung cấp cho người dùng công cụ xác thực đăng nhập một lần. Công cụ này xác thực người dùng đăng nhập vào mọi hệ thống có tích hợp giải pháp SSO, vì vậy, người dùng chỉ cần nhớ một cặp tên truy cập/mật khẩu duy nhất.
Khi cập nhật mật khẩu và tên đăng nhập, người dùng chỉ cần cập nhật một lần cho toàn bộ các hệ thống có yêu cầu xác thực người dùng.
Khi đã đăng nhập vào một hệ thống chứa các hệ thống con có tích hợp giải pháp SSO, người dùng có thể dễ dàng truy nhập vào các hệ thống con này mà không cần phải xác thực lại trong một khoảng thời gian nào đó, tùy thuộc vào chính sách quản trị.
Đối với nhà cung cấp dịch vụ, quản trị hệ thống:
Người quản trị chỉ cần bảo mật và quản lý thông tin đăng ký của người dùng một lần, vì vậy có thể giảm dung lượng cơ sở dữ liệu và tránh được các xung đột nảy sinh do phải xử lý mật khẩu của các hệ thống khác nhau, tăng khả năng mở rộng và triển khai các chiến lược bảo mật.
Người quản trị có thể thay đổi và cập nhật thông tin được bảo mật của người dùng khi cần thiết, một cách dễ dàng hơn so với việc thay đổi ở từng hệ thống riêng lẻ mà người dùng đó được phép truy cập. Điều này rất hữu ích khi người dùng thay đổi vị trí của mình với các cấp độ bảo mật khác nhau.
Nhược điểm của giải pháp SSO
Việc xử lý một loạt các hệ thống con có tích hợp giải pháp SSO không đơn giản, bởi vì mỗi hệ thống con có thể hoạt động trên các nền phần cứng và phần mềm khác nhau. Vì vậy, khi cài đặt sẽ phải giải quyết nhiều vấn đề liên quan đến tính tương thích và đồng bộ giữa các hệ thống.
Khi đã được xác thực thành công, người dùng có thể truy nhập vào nhiều ứng dụng trong hệ thống. Bởi vậy, nếu không được bảo mật tốt tại các hệ thống con, thì đối tượng tấn công khi tiếp cận vào một ứng dụng có thể tấn công vào toàn bộ hệ thống. 
Các kỹ thuật mang tính mở áp dụng với hệ thống hoặc chưa được chuẩn hóa, hoặc chưa được cung cấp, có thể gây mâu thuẫn và không tương thích với các sản phẩm khác.
Thách thức đối với giải pháp SSO là làm việc theo kiến trúc, các cơ chế bảo mật độc lập đối với các nền ứng dụng. Để thuận tiện và đơn giản hơn khi giải quyết nhược điểm của SSO, người ta thường đi theo hướng xây dựng các ứng dụng sử dụng cơ sở hạ tầng bảo mật, xác thực người dùng chung, thông suốt giữa các ứng dụng. Điều này đòi hỏi phải có định dạng chung khi thể hiện các thông tin xác thực hoặc ủy nhiệm, sao cho tất cả các ứng dụng đều có thể hiểu và chấp nhận chúng. Đồng thời, phải đảm bảo được các ủy nhiệm là đúng đắn.
Mặc dù có một số nhược điểm, nhưng giải pháp SSO vẫn đang được triển khai rộng rãi ở nhiều nước trên thế giới, trong nhiều hệ thống thông tin có nhu cầu xác thực và bảo mật. Nó được đánh giá là một trong các giải pháp hiệu quả, tiện dụng và kinh tế khi triển khai trên diện rộng. Các vấn đề nêu trên sẽ được giải quyết trong thời gian tới khi chúng ta tăng cường chuẩn hóa và có các chính sách cụ thể cho vấn đề này. 
2. Một số mô hình SSO thực tế
Các hệ thống xác thực SSO đang được sử dụng rộng rãi là: CAS (Central Authentication Service), WebAuth. RSA Single Sign On Manager, Open Single Sign - On (OpenSSO) hoạt động dựa trên Token, Java Open SSO (JOSSO).
Open SSO Enterprise
OpenSSO là một sản phẩm mã nguồn mở của SUN. Nó là một sản phẩm đơn lẻ, kết hợp các tính năng của Sun Java System. Access Manager, Sun Java System Federation Manager và Sun System SAML v2 Java Plugin, kiểm soát truy nhập, đảm bảo an toàn các dịch vụ web và các dịch vụ định danh Web. Khi truy cập vào những tài nguyên được bảo vệ của người dùng, yêu cầu truy cập cần được xác thực và phải có đủ quyền truy cập. Khi một người gửi yêu cầu để truy cập tài nguyên được bảo vệ, policy agent chặn yêu cầu này và kiểm tra. Nếu OpenSSO token được tìm thấy không hợp lệ, policy agent sẽ yêu cầu máy chủ tiến hành xác thực và cấp phép (Hình 1).

Hình 1: Mô hình đăng nhập duy nhất OpenSSO
Policy agent là ứng dụng web với nhiệm vụ ngăn tất cả yêu cầu đến ứng dụng, để kiểm tra xem người dùng đã xác thực hay chưa (Hình 2).


Hình 2: Cơ chế hoạt động của OpenSSO
Cơ chế hoạt động của OpenSSO như sau:
- Từ trình duyệt, người dùng kết nối đến ứng dụng web.
- Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không. Nếu token chưa tồn tại thì Policy Agent sẽ chuyển trình duyệt đến OpenSSO máy chủ.
- OpenSSO máy chủ xác thực người dùng thông qua trang đăng nhập. Người dùng nhập tên truy cập/mật khẩu để xác thực.
- OpenSSO (tạo ra session cho người dùng và kích hoạt nó nếu xác thực thành công).
- OpenSSO gửi token cho trình duyệt (trình duyệt sẽ lưu token dưới dạng cookie) và Trình duyệt sẽ gửi token đến cho Agent. 
- Policy Agent sẽ lấy thông tin token gửi đến OpenSSO máy chủ để kiểm tra. 
- OpenSSO sẽ gửi thông tin đăng nhập (tên truy cập, mật khẩu) và thông tin vai trò đến Agent nếu kiểm tra token hợp lệ.
- Policy Agent sẽ quyết định cho phép truy cập ứng dụng hay không và ghi thông tin session trên URL.
Giải pháp Dịch vụ xác thực trung tâm CAS
CAS (Central Authenticate Service) là một giải pháp SSO mã nguồn mở được phát triển bởi đại học Yale, với các tính năng như sau: 
- CAS hỗ trợ nhiều thư viện phía máy khách được viết bởi nhiều ngôn ngữ: PHP, Java, PL/SQL. Nó lấy thông tin SSO thông qua cookie. Cookie này sẽ bị hủy khi người dùng đăng xuất khỏi CAS hoặc đóng trình duyệt. Cookie được sinh ra bởi CAS, còn được gọi là TGC (Ticket Granting Cookie) chứa một ID duy nhất.
- CAS cung cấp nhiều trình quản lý xác thực (authenticate handler) khác nhau. CAS xác thực nhiều loại thông tin người dùng như tên truy cập/mật khẩu, chứng chỉ khóa công khai X509,... để xác thực những thông tin người dùng khác nhau này, CAS sử dụng những trình quản lý xác thực tương ứng.
- CAS cung cấp tính năng “Remember me”. Người phát triển có thể cấu hình tính năng này trong nhiều file cấu hình khác nhau và khi người dùng chọn “Remember me” trên khung đăng nhập, thì thông tin đăng nhập sẽ được ghi nhớ với thời gian được cấu hình. Khi người dùng mở trình duyệt thì CAS sẽ chuyển đến service URL tương ứng mà không cần hiển thị khung đăng nhập.
Nguyên tắc hoạt động của CAS như sau:
Chứng thực người dùng với máy chủ CAS
- Người dùng nhập tên truy cập/mật khẩu vào khung đăng nhập. Các thông tin này được truyền cho CAS máy chủ thông qua giao thức HTTPS.
- Xác thực thành công, TGC được sinh ra và thêm vào trình duyệt dưới hình thức là cookie. TGC này sẽ được sử dụng để đăng nhập với tất cả các ứng dụng (Hình 3).


Hình 3: Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ
Truy cập vào ứng dụng của người dùng
Trường hợp người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ:
- Người dùng truy xuất ứng dụng thông qua trình duyệt.
- Ứng dụng lấy TGC từ trình duyệt và chuyển nó cho CAS máy chủ thông qua giao thức HTTPS.
- Nếu TGC này là hợp lệ, CAS máy chủ trả về một Service Ticket (ST) cho trình duyệt, trình duyệt truyền ST vừa nhận cho ứng dụng.
- Ứng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho CAS máy chủ.
- CAS máy chủ sẽ trả về ID của người dùng cho ứng dụng, mục đích là để thông báo với ứng dụng là người dùng này đã được chứng thực bởi CAS máy chủ.
- Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.
Trường hợp người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS máy chủ:
- Người dùng truy xuất ứng dụng thông qua trình duyệt. Vì chưa nhận được TGC nên ứng dụng sẽ chuyển hướng người dùng cho CAS máy chủ.
- Người dùng cung cấp tên truy cập/mật khẩu của mình thông qua khung đăng nhập để CAS xác thực. Thông tin được truyền đi thông qua giao thức HTTPS.
- Xác thực thành công, CAS máy chủ sẽ trả về cho trình duyệt đồng thời cả TGC và ST.
- Trình duyệt sẽ giữ lại TGC để sử dụng cho các ứng dụng khác (nếu có) và truyền ST cho ứng dụng nêu trên.
- Ứng dụng chuyển ST cho CAS máy chủ và nhận về ID của người dùng.
- Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng (Hình 4).


Hình 4: Người dùng truy cập ứng dụng mà chưa chứng thực với CAS
3. Ứng dụng thực tế 
Cổng thông tin Liferay được xây dựng dựa trên mã nguồn mở, viết bằng ngôn ngữ java và phát hành dưới bản quyền GNU LGPL. Cổng thông tin Liferay cho phép người dùng cài đặt những chức năng chung cho website. Đó là những bộ phận chức năng cơ bản được gọi là portlet. Liferay hỗ trợ những plugin mở rộng đa ngôn ngữ, bao gồm cả portlet cho PHP và Ruby. Cổng thông tin Liferay chạy trên bất cứ môi trường chạy Java Runtime Environment nào. Liferay đi cùng bộ với server Apache Tomcat. 
Alfresco là phần mềm nguồn mở theo giấy phép GNU, dùng để quản lý tài liệu, hỗ trợ cho các doanh nghiệp trong việc tổ chức lưu trữ tài liệu điện tử một cách khoa học và hiệu quả. Alfresco dùng cho Microsoft Windows và các hệ điều hành Linux, Solaris với hai phiên bản: Alfresco Community Edition là phần mềm dựa trên các chuẩn mở và giấy phép mã nguồn mở LGPL. Alfresco Enterprise Edition là phiên bản thương mại dùng cho doanh nghiệp. Alfresco bao gồm: kho quản trị nội dung; web portal framework dùng cho việc quản lý và sử dụng nội dung được lưu trữ, một giao thức CIFS hỗ trợ tương thích với hệ thống file trên Microsoft Windows và các hệ điều hành Linux, Solaris; hệ thống quản lý nội dung web có khả năng xây dựng các ứng dụng web và website tĩnh qua Apache Tomcat; công nghệ tìm kiếm Lucene; công nghệ quản lý quy trình làm việc jBPM. Hệ thống Alfresco được phát triển trên công nghệ Java.
Người ta có thể xây dựng và tích hợp thành công hệ thống Liferay với CAS và tích hợp thành công Alfresco với CAS để thực hiện quá trình truy cập một lần trên hai ứng dụng.
TS. Hồ Văn Hương, ThS. Đào Thị Ngọc Thùy tổng hợp
Nguồn http://antoanthongtin.vn/Detail.aspx?CatID=8ab90f49-a562-4157-a607-d2474bf129a9&NewsID=1caffb79-e759-4855-91fc-76840dfc5424

Wednesday, March 23, 2016

What's a Pixel?

https://developer.appway.com/screen/ShowSingleRecipe/selectedRecipeId/1429057950522
Created by L. Mathis on 27.11.2014 

Problem 
A lot of Screen components in Appway ask me to enter pixel values. For example, the Adaptive Flow Layout has properties like these.



However, my phone has a 400 DPI screen, meaning it shows 400 pixels per inch. My PC only has about a 100DPI screen, so it only shows about 100 pixels. Does this mean that the same value is four times larger on a PC than on a phone? What exactly does "pixel" really mean?
Solution
This question would have been really easy to answer a decade ago: "A pixel is the glowing little dot on your CRT screen." Unfortunately, we don't have these screens anymore, and pixels don't really mean that anymore; at least not the kinds of pixels you're entering into a Screen component property.

There's a short answer and a long answer to your question. Let's start with the short answer.

The Short Answer

A pixel in Appway is a unit of length that appears to be very roughly the same size on most devices. Typically, it's roughly 1/100th of an inch. It has nothing to do with the glowing dots on your screen, unless you happen to have an older computer that has very large dots on its screen.

The Long Answer

To understand exactly what a pixel in Appway actually is, one needs to understand what happens when a computer renders an Appway screen, because during that process, different kinds of pixels are involved:

  • Logical pixels
  • Rendered pixels
  • Physical pixels

Logical Pixels

First, we start out with logical pixels: That's what you enter into a component's properties field. It's not really a pixel at all; instead, it's a rough measure whose length is "about what a pixel used to be, back when there was only one kind of pixel, taking into account how far away the screen is from your eyes". In the CSS spec, which Appway uses, it is defined as 0.75pt. 1pt, meanwhile, is defined as 1/72 of an inch. However, an inch in CSS isn't necessary an actual inch. CSS allows devices to use the pixel as an anchor unit, which means that the inch is calculated from what the device thinks a pixel's size should be. And what does the device think a pixel's size should be? It depends on how far away from her eyes the user is likely to hold her device:

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).


On a TV (which is usually far away from you), a logical pixel could be larger than a mm, while on a phone (which you hold much closer), it could be smaller than a quarter of a mm.

In other words, depending on what kind of device you use, logical pixels end up being a different physical size. For the devices users are likely to use, they're typically in the very rough neighborhood of 1/100th of an inch. At this stage, pixels aren't areas or dots or anything like that. They're a unit of length, like a millimeter or an inch — but smaller, not defined precisely, and of a slightly different size depending on the device.

In short, you use pixels to specify size in a somewhat device-independent way. 400 logical pixels on a desktop PC are roughly the same apparent size as 400 logical pixels on a smartphone. That's why we use logical pixels to specify sizes in Appway: they translate across devices.

Rendered Pixels

When the OS renders a screen, logical pixels are translated to rendered pixels. The translation from logical pixels to rendered pixel happens using the device-pixel-ratio. This ratio specifies how many logical pixels translate to how many rendered pixels for each device. This does not have to be an even value. Since logical pixels are not actual pixels, but just a unit of length, one logical pixel can translate to 1.5 rendered pixels, for example.

An iPhone 4 has a device-pixel-ratio of 2, meaning that one logical pixel length gets translated to the length of two rendered pixels. Therefore, one logical pixel (which is one pixel wide and one pixel high) translates to four rendered pixels (two pixels high and two pixels wide). Other devices have device-pixel-ratios of 3 or 4, so one logical pixel can be rendered as 9 or 16 rendered pixels.

At this point, you could assume that we're done, but not quite yet. One additional thing is about to happen: rendered pixels have to be drawn on an actual screen.

Physical Pixels

For most devices, showing rendered pixels on a physical screen involves no additional translation. The size of a rendered pixel is equal to the size of a physical pixel on the screen. This is not the case for all devices, however. Some devices (such as the iPhone 6 Plus, or a Retina MacBook Pro with scaled resolution enabled) render pixels at a higher pixel density (and thus at a smaller pixel size, but a larger image size) than the actual screen can display. When the rendered pixels are shown on the screen, the rendered image is scaled down to the size of the screen.

This website shows the kinds of graphical artifacts this can produce:
http://oleb.net/blog/2014/11/iphone-6-plus-screen/

PenTile Screens

For completeness' sake, I'll also add that a physical pixel does not always mean the same thing. On a normal screen, one physical pixel has three sub-pixels for the three colors shown by an RGB screen: red, green, blue. However, some screens (e.g. PenTile OLED screens) only have two sub-pixels per pixel. This means that one rendered pixel is often represented by more than one physical pixel, since the rendered pixel "borrows" a colored sub-pixel from a neighboring pixel.



Conclusion: Putting it all together

Logical pixels, set as component properties, are a unit of length roughly similar in size on different devices, and not an actual colored dot. Logical pixels are first translated into rendered pixels, and then scaled to actual device pixels, which then may be actual pixels with three different sub-pixels.



(The PaintCode website has a nice guide that explains this particular process — from logical pixels to rendered pixels to physical pixels — for iPhones.)

In reality, this level of fine-grained detail is only provided for informational purposes: All you need to know is that what Appway calls "a pixel" is actually not a physical pixel on a screen. Instead, it's a unit of length that is roughly the same size across different devices.

iPhone 6 Screen Size and Web Design Tips

http://www.kylejlarson.com/blog/iphone-6-screen-size-web-design-tips/

Apple updated its iPhone a bit ago making the form factor much bigger. The iPhone 6 screen size is both wider and taller and the iPhone 6 Plus also has a higher pixel density. This is an update to my previous post about designing websites for the iPhone 5. It’ll cover these new screen sizes and try to clarify how this all works.
Update: Apple has released the iPhone 6s and iPhone 6s Plus. The iPhone 6s screen size is identical to the previous iPhone 6 versions, so feel free to follow the existing sizes below.
Update 2: Apple has released the iPhone SE which is the same size as the iPhone 5.

iPhone Screen Measurements

There are a few different values to consider when looking at the iPhone screen sizes. I’m going to get these values defined here so the chart below makes more sense:
iPhone Display Size (inches) – This is diagonal measure of the screen, from corner to corner, just like you’d measure a TV.
iPhone Screen Size (points) – These points are the size that the device is using for coordinates. If you’re designing for the web (using CSS or JavaScript) these values will be helpful. iPhones use Retina screens which have a higher pixel density. This means they take the larger iPhone resolution (mentioned above) and compress those pixels into a smaller space to make the image look sharper.
iPhone Rendered Pixels – This is the full number of pixels that are being rendered. This is the value you get when you apply the multiplier (1x, 2x, 3x) the device uses to the screen size in points. If you’re creating an image and want it at the max resolution, this is the size you’d use. I’ve also written an article on Retina images if you’d like to learn more.
iPhone Physical Pixels – This is the actual screen’s pixel resolution. The iPhone 6 Plus is using a a larger image resolution on a screen with a smaller number of physical pixels, so it needs to be downsampled to this size. This value is really only important in a specifications perspective, but shouldn’t really affect your designs.
iphone 6 plus screen

iPhone Screen Size Comparison

This image shows the browser screen size of the iPhones for use when writing CSS. See the table below for all the measurements of each phone. If you’re using iOS 8 the Safari menu height is consistent across all the iPhones.
iphone 6 screen size

iPhone 4 iPhone 5(SE) iPhone 6 iPhone 6 Plus
Display Size 3.5 in 4 in 4.7 in 5.5 in
Screen Size 320 x 480 points 320 x 568 points 375 x 667 points 414 x 736 points
Rendered Pixels 640 x 960 (@2x) 640 x 1136 (@2x) 750 x 1334 (@2x) 1242 x 2208 (@3x)
Physical Pixels 640 x 960 640 x 1136 750 x 1334 1080 x 1920
Pixels Per Inch (PPI) 326 326 326 401
Browser Size Portrait 320 x 372 px
(320 x 440* / 320 x 460**)
320 x 460 px
(320 x 528* / 320 x 548**)
375 x 559 px
(375 x 627* / 375 x 647**)
414 x 628 px
(414 x 696* / 414 x 716**)
Browser Size Landscape 480 x 212 px
(480 x 280* / 480 x 300**)
568 x 212 px
(568 x 280* / 568 x 300**)
667 x 267 px
(667 x 335* / 667 x 355**)
736 x 306 px
(736 x 374* / 736 x 394**)
* – measurements with the small browser navigation bar
** – measurements without any browser chrome for a web app
Note that the iPhone 6 Plus is a 3x screen. For the previous iPhones you can double the screen size values to figure out the max size of your retina image, but on the iPhone 6 Plus you’ll want to triple that value (i.e. a full screen graphic would be 1242 x 2208).

Using the iPhone 6 Screen Size for Web Design

If you’re coding your site using Responsive design in order to fit the iPhone well, you may have some sizing issues if you don’t tell the device not to zoom in. You can do this by adding this viewport metatag into the head of your site:
<meta name="viewport" content="initial-scale=1.0">

iPhone 6 Startup Screen

If you’re going to be setting up your website so users can save it and run it as a web app you can add a startup image to display when the page is loading.
First add the web app meta tag (also make sure you’re not using a width in your viewport meta tag as this can cause issues):
<meta name="apple-mobile-web-app-capable" content="yes" />
Then create startup images at these sizes for compatibility with each phone:
iPhone 1 – 3gs: 320 x 460 px
iPhone 4 – 4s: 640 x 920 px
iPhone 5(SE): 640 x 1096 px
iPhone 6: 750 x 1294 px
iPhone 6 Plus: 1242 x 2148 px
Then add the code in your page’s header to link to them:
<link rel="apple-touch-startup-image" href="images/ios_startup.png"> 
<link rel="apple-touch-startup-image" href="images/ios_startup@2x.png" sizes="640x920">
<link rel="apple-touch-startup-image" href="images/ios_startup-large@2x.png" sizes="640x1096">
<link rel="apple-touch-startup-image" href="images/ios_startup-6@2x.png" sizes="750x1294">
<link rel="apple-touch-startup-image" href="images/ios_startup-6-plus@3x.png" sizes="1242x2148">

iPhone 6 Icons

When designing iPhone 6 icons you’ll notice there is a new size for the higher pixel density iPhone 6 plus. If you’d like to add an icon to your site that people will see when they save it to their homescreen, take a look at my article on creating an iPhone icon, which includes the sizes you’ll need.
====================

https://www.google.com/search?q=rendered+pixels+vs+physical+pixels&biw=1366&bih=633&tbm=isch&tbo=u&source=univ&sa=X&sqi=2&ved=0ahUKEwiAuKK19dXLAhVnKKYKHZYtCMkQsAQIPQ

The Difference Between Image Dimensions and Image Resolution?

Dimension refers to the actual measurement of the picture. Its width and height. This is measured in pixels, inches or cm.
The resolution of an image refers to the pixel density. It measures how many pixels there are per inch (or cm) of space on the picture.
If the picture is 200 pixels wide and it is also 2 inches wide, it would have a pixel resolution of 100 pixels per inch (ppi)

https://answers.yahoo.com/question/index?qid=20101122140629AAqZFMB