[Discovery] Thứ tự ra đời ảnh hưởng như thế nào đến mỗi người?

Tinhte-gia-dinh-02.

Một số bậc cha mẹ cho rằng anh em trong gia đình thường có tính cách, khả năng, sở thích khác nhau phụ thuộc vào thứ tự ra đời của nó. Hơn nữa, một số người còn cho rằng thứ bậc anh em còn có ảnh hưởng tới sức khỏe, trí tuệ và đặc điểm tính cách của đứa trẻ. Vậy thật ra, thứ hạng trong gia đình ảnh hưởng như thế nào tới mỗi con người? Rất nhiều nghiên cứu đã được thực hiện nhằm lý giải bí ẩn này và các nhà khoa học đã phát hiện ra được một số mối tương quan thú vị nhưng cũng đầy tranh cãi.

Các nhà nghiên cứu nhìn nhận rằng, thứ bậc anh em là một lĩnh vực cực kỳ khó nghiên cứu và cũng vì thế, các kết luận vẫn còn gây nhiều tranh cãi cho đến ngày nay. Có rất nhiều yếu tố bên ngoài xoay quanh chủ đề này như tuổi của mỗi người trong gia đình, họ cách nhau bao nhiêu tuổi, gia đình đó có tổng cộng bao nhiêu đứa con, giới tính của mỗi đứa con, hoàn cảnh môi trường nuôi dưỡng và nhiều điều kiện kinh tế – xã hội khác. Thật sự, các nhân tố trên không dễ phân lập nhằm xác định ảnh hưởng của mỗi yếu tố tới thứ bậc anh em và từ đó, biết được tác động tới mỗi thành viên trong nhà.

Hồi năm 1983, 2 nhà nghiên cứu Cécile Ernst và Jules Angst đã thực hiện một nghiên cứu lớn, kéo dài từ năm 1946 đến năm 1980 nhằm tìm câu trả lời cho thắc mắc trên. Từ đó đến nay, nhiều nhà tâm lý học đã tối thiểu hóa vai trò và ảnh hưởng của thứ bậc anh em đối với mỗi cá nhân. Và một số ý kiến còn cho rằng nó không thật sự có ảnh hưởng đến mỗi người. Nhưng trong suốt 4 thập kỷ qua, nhiều nhà tâm lý học vẫn tiếp tục nghiên cứu chủ đề này và cho đến hiện tại, họ đã thu được một số phát hiện.

Thứ tự ra đời và tính cách

Tinhte-Alfred Adler.
Alfred Adler (1870 – 1937)

Alfred Adler (1870 – 1937), bác sĩ, chuyên gia tâm thần học, người sáng lập trường phái tâm lý học cá nhân, là một trong những nhà nghiên cứu đầu tiên sử dụng thứ tự anh em trong gia đình để đánh giá tâm lý khách hàng của ông. Và Frank Sulloway, giáo sư tâm lý học hiện đại thuộc Viện công nghệ Massachusetts (MIT) đã nghiêm túc kiểm chứng các tiếp cận của tiền bối Alfred Adler.

Trong cuốn sách “Born to Rebel” xuất bản năm 1996, Sulloway đã đề xuất 5 đặc điểm tính cách của mỗi cá nhân là sự cởi mở (openness), sự tận tâm (conscientiousness), sự dễ chịu (agreeableness), tính hướng ngoại (extraversion) và tâm lý bất ổn (neuroticism). Ông cho rằng, thứ tự ra đời có ảnh hưởng nhất định tới tất cả các đặc điểm này. Theo Sulloway, đứa con đầu lòng sẽ có sự vâng lời nhiều hơn, trong khi những đứa con tiếp theo trong gia đình thể hiện sáng tạo cao hơn và có xu hướng từ chối sự áp đặt. Ông còn phát hiện rằng những người có cùng thứ hạng trong gia đình sẽ có nhiều điểm chung hơn so với anh em của họ.

TInhte-photo-frank-bears.
Frank Sulloway, giáo sư tâm lý học hiện đại, người đã đề xuất 5 đặc điểm tính cách của con người và sức ảnh hưởng của thứ bậc ra đời với 5 đặc điểm này

Và những quan điểm trong cuốn sách của Sulloway đã nhận được nhiều ý kiến trái chiều, tạo nên các cuộc tranh cãi chưa có hồi kết. Giáo sư xã hội học Jeremy Freese đến từ Đại học Northwestern là 1 trong những người phản bác hướng tiếp cận của Sulloway và thậm chí ông còn cho rằng Sulloway đã làm giả dữ liệu. Tuy nhiên, cuốn sách của Sulloway đã khơi mào cho sự ra đời của hàng trăm nghiên cứu khác dựa trên quan điểm của Sulloway.

Hồi năm 2010, tiến sĩ xã hội học người Đức Daniel Eckstein cùng các đồng nghiệp đã tiến hành phân tích một cách đầy đủ nhằm kiểm chứng và hoàn thiện ý tưởng của Ernst và Angst. Dựa trên kết quả của hơn 200 nghiên cứu sẵn có, nhóm có thể thống kê được ảnh hưởng của thứ bậc anh em đến đặc điểm tính cách và phong cách sống của mỗi cá nhân. Họ phát hiện ra rằng một số đặc điểm tính cách có mối liên hệ chặt chẽ với thứ hạng ra đời.

Tinhte-200-nghien-cuu.
Thống kê 200 nghiên cứu về mối tương quan giữa tính cách cá nhân và thứ tự ra đời (Cột bên trái là đặc điểm tính cách với n là tần số xuất hiện trong 200 nghiên cứu và cột bên phải là vị trí xuát hiện trong nghiên cứu.)

Cụ thể, những đứa trẻ đầu lòngh có xu hướng đạt được những đạt được những kết quả và thành công cao hơn. Những người là con một trong già đình luôn khao khát đạt được thành tựu. Những đứa con giữa thường dễ gần gũi. Và cuối cùng là những đứa con út, thường hướng tới các giao tiếp trong cuộc sống xã hội. Bên dưới đây là bảng thống kê 200 nghiên cứu trong cơ sở dữ liệu của nhóm.

Dựa theo bảng thống kê trên, rõ ràng là có sự liên kết giữa thứ tự trong gia đình và đặc điểm cá nhân cũng như sở thích nghề nghiệp. Một nghiên cứu hồi năm 2001 cũng chỉ ra rằng những đứa trẻ sinh sau thường đi theo khuynh hướng nghệ thuật và các nghề có liên quan đến tính hướng ngoại. Trong khi đó, những đứa con một và con đầu lòng thường theo đuổi những gì thuộc về trí tuệ. Đồng thời, các nhà nghiên cứu không nói rằng đây là một vấn đề bẩm sinh hay di truyền. Họ cho rằng đây là kết quả bởi sự định hướng của cha mẹ.

Mặt khác, thứ tự sinh trong gia đình cũng ảnh hưởng tới tính cạnh tranh của con người. Các nhà nghiên cứu đã chỉ ra rằng những đứa con đầu lòng thường theo đuổi “mục tiêu làm chủ” (Mastery Goals). Nhà tâm lý Bernd Carette tại Đại học Gent cho rằng, có thể nguyên nhân của điều này là do những đứa con đầu lòng đã nhận được sự đối xử khác biệt của cha mẹ từ thời thơ ấu, do đó, chúng sẽ dùng chính các tiêu chuẩn do cha mẹ đặt ra để tự đánh giá năng lực của mình.

Thú vị hơn, thứ tự sinh còn ảnh hưởng tới cách mỗi cá nhân hướng ngoại. Một nghiên cứu hồi năm 2013 cho thấy con đầu lòng biểu hiện sự làm chủ nhiều hơn, trong khi những đứa con thứ có xu hướng chan hòa hơn khi hướng ngoại. Mặt khác, những đứa con đầu lòng sẽ ít bị chi phối và quyết đoán hơn so với con thứ. Các nhà nghiên cứu lập luận rằng có thể chế độ nuôi day nghiêm ngặt và khắ khe đối với con đầu lòng khiến những đứa trẻ này vâng lời hơn, và sẽ tham chiếu mối quan hệ đó vào cuộc sống xã hội khi lớn.

Những mâu thuẫn trong nghiên cứu vẫn tiếp diễn

Tinhte-gia-dinh-01.
Ảnh minh họa

Hồi năm 1998, các nhà khoa học Canada đã khảo sát 1022 hộ gia đình và phát hiện ra rằng những đứa con đầu lòng bảo thủ hơn, đạt được thành công nhiều hơn và cũng tận tâm hơn so với con thứ. Những đứa con thứ lại được đánh giá là phá cách hơn, phóng khoáng và dễ chịu hơn. Tuy nhiên, kết luận này vẫn chưa thật sự phổ quát do dựa trên các đánh giá từ chính những thành viên trong gia đình. Một nghiên cứu khác dựa trên đánh giá từ những người không thuộc gia đình như bạn bè, đồng nghiệp, họ hàng lại cho biết là không có sự khác biệt trong thứ bậc anh em.

Thật ra, sự mâu thuẫn trên không quá đáng ngạc nhiên. Một vấn đề tồn tại trong cả 2 nghiên cứu trên chính là việc đánh giá nhân cách 1 anh A nào đó sẽ khác nhau khi người đánh giá là cha mẹ, anh chị em, bạn bè,… Nguyên nhân là do trong quá trình sinh sống, mối quan hệ giữa anh A với những người này là khác nhau. Đồng thời, những người sống chung gia đình anh A sẽ kết luận về anh khác với những người khác. Do đó, các nhà khoa học lập luận rằng có thể thứ bậc anh em chỉ ảnh hưởng đến với cá nhân đó trong phạm vi gia đình, và tác động này không thể tham chiếu vượt khỏi phạm vi này.

Bên cạnh đó, một nghiên cứu còn kết luận rằng mối quan hệ anh em sẽ liên tục phát triển trong suốt đời người. Mối quan hệ này luôn được tiến triển một cách chủ động song song với những hoàn cảnh xã hội. Đây là những nhu cầu thay đổi do tác động của cạnh tranh xã hội lẫn nhu cầu sinh học trong cá nhân mỗi người.

Một số mối liên hệ tiêu biểu

Tinhte-gia-dinh-03.
Ảnh minh họa

Trí tuệ là khía cạnh đặc biệt gây tranh cãi nhiều nhất. Những người ủng hộ cho rằng những đứa con đầu lòng sẽ có điểm kiểm tra trí thông minh cao hơn. Một nguyên nhân được đưa ra là con đầu lòng nhận được sự chú ý và nguồn lực từ cha mẹ nhiều hơn. Nhà tâm lý học nổi tiếng Robert Zajonc (1923-2008)cho biết thêm rằng con đầu lòng còn thể hiện khả năng giao tiếp bằng lời nói tốt hơn so với con thứ. Nguyên nhân ông đưa ra là do con đầu tích lũy được ngôn ngữ người lớn từ sớm và nhiều hơn so với con thứ.

Một nguyên nhân khác là tình trạng kinh tế xã hội của gia đình. Gia đình càng nhỏ thì thời gian và nguồn lực từ cha mẹ càng được mang đến cho con cái nhiều hơn. Đồng thời, tuổi sinh con của người mẹ cũng có thể là một nhân tố. Những bà mẹ trẻ có xu hướng trình độ thấp, thu nhập thấp nhưng lại tạo ra gia đình đông con, từ đó dẫn tới nguồn lực dành cho con cái kém hơn.

Hồi năm 2009, một nghiên cứu dẫn đầu bởi nhà tâm lý học Timothy Hartshorne đã củng cố kết luận trước đó của Sulloway rằng người ta thường có nhiều điểm chung với ai đó cùng thứ bậc gia đình. Hơn nữa, mối quan hệ giữa 2 người nam – nữ có cùng thứ bậc sẽ lâu dài và lãng mạn hơn.

Về mặt sức khở, người ta cũng nhận thấy rằng con đầu lòng có khả năng hấp thụ đường kém hơn và có huyết áp vào ban ngày cao hơn con thứ. Đồng thời, con đầu lòng có nguy cơ mắc các bệnh về trao đổi chất và tim mạch cao hơn khi trưởng thành. Các nhà khoa học cho rằng nguyên nhân có thể do sự thay đổi vật lý trong cổ tử cung người mẹ trong lần mang thai đầu tiên.

Trên đây là những yếu tổ tiêu biểu thể hiện mối tương quan giữa thứ tự anh em và khía cạnh sinh học, cá nhân mỗi người. Bên cạnh đó, các nhà nghiên cứu đã chỉ ra rất nhiều mối tương quan khác xoay quanh chủ đề này. Đồng thời, các nghiên cứu khi công bố đều nhận được cả 2 luồng ý kiến trái chiều nhau và tranh cãi vẫn cứ thế tiếp tục. Hy vọng rằng các nhà nghiên cứu sẽ sớm cùng nhau giải quyết được vấn đề được xem như bí ẩn khoa học còn tồn đọng đến ngày nay. Hy vọng bài viết cung cấp được một số thông tin thú vị cho các bạn. Cám ơn đã theo dõi bài viết. Chúc vui vẻ.

Advertisements

[Discovery] Các bộ phim có cảnh xe hơi rượt đuổi nhau hay nhất

car-stunt (2). ​Trong các phim hành động thì cảnh xe cộ rượt nhau ào ào ngoài đường dường như không thể thiếu, hiện nay công nghệ CGI đã rất tiến bộ và người ta đã có thể dựng hoàn toàn những cảnh đó trên máy tính, tuy vậy việc sử dụng những chiếc xe thật cho các cảnh quay đó vẫn cho thước phim cảm giác đáng giá hơn, xem thật hơn. Mời các bạn điểm qua 10 cảnh ngoạn mục do các chiếc xe thật tham gia “diễn xuất” trong phim ảnh.

Captain America: The Winter Soldier
Đây được xem là một trong những cảnh quay ngoạn mục nhất trong phần 2 Captain America: Chiến Binh Mùa Đông, lúc Nick Fury đang tự lái chiếc SUV của mình và bị Bucky Barnes truy sát. Bucky sau đó chỉ cần “Đằng sau, quay!” là né được nguyên chiếc xe trờ tới, rất thú vị. Về sau Nick đã nhanh trí giả chết để điều tra âm mưu lũng đoạn tổ chức SHIELD của Hydra.

car-stunt (4).
Batman: The Dark Knight

Cảnh quay cho thấy đoạn rượt đuổi nghẹt thở giữa Người Dơi và Joker, lúc này Joker lái một chiếc container dài thoòng để chạy trốn, cuối cùng Batman phải hạ chiếc xe nhằm bắt sống Joker.

car-stunt (6).
The Blues Brothers

The Blues Brothers ra rạp năm 1980, trong phim có một cảnh tất cả xe cảnh đang truy đuổi trên đường không may gặp nạn, hàng chục chiếc xe trong nháy mắt trở thành sắt vụn sau màn nhào lộn trên không.

car-stunt (9).
Speed

Tốc Độ (1994) là một trong những phim hành động kinh điển, chắp cánh cho sự nghiệp diễn xuất của Keanu Reeves và Sandra Bullock. Trong phim Speed, Keanu vô vai cảnh sát trẻ Jack Traven vô tình phát hiện âm mưu đặt bom chiếc xe bus 50 chỗ của kẻ khủng bố. Có đoạn chiếc xe phải bay qua cây cầu đang thi công bị hụt khúc giữa.

car-stunt (5).
The Man With the Golden Gun (1974)

Đây là một trong những phim về Điệp viên 007 dưới sự diễn xuất của Roger Moore. Trong phim có cảnh chiếc xe màu đỏ của Bond bay qua cây cầu gỗ, trước khi đáp xuống bờ bên kia còn kịp lộn ngang một vòng đẹp mắt.

car-stunt (2).
Terminator 2: Judgment Day

Trong phim có cảnh robot T-1000 lái xe tải truy sát cậu nhóc John Conner, chiếc xe đâm sập thành cầu và phim thẳng xuống dòng kênh như muốn cán nát cậu bé.

car-stunt (1).
Death Proof

4 cô gái lái chiếc xe rong chơi, phiêu theo điệu nhạc mà không ngờ rằng chiếc xe đen đang canh sẵn.

car-stunt (3).
Mad Max

Chiếc mô tô bị Max truy đuổi không kịp né chiếc xe tải đi ngược chiều.

car-stunt (7).
The Bourne Identity

Huyền thoại Bourne và cảnh quay nghẹt thở khi bị hàng chục xe cảnh sát truy đuổi sát nút.

car-stunt (1).
Furious 6

Series phim Fast & Furious có rất nhiều cảnh rượt đuổi xe ấn tượng, dưới đây là vài cảnh trong đó.

[Discovery] 10 thông tin thú vị về ngày Giáng Sinh

Tinhte_Giang-Sinh-201403.
Ảnh minh họa. Một bạn trẻ yêu công nghệ dán da điện thoại và cài đặt hình nền hình cây thông để mừng ngày lễ Giáng Sinh.

Chúng ta đang sống trong không khí Giáng Sinh tràn ngập khắp mọi nơi. Đây là 1 trong những ngày lễ quan trọng trong năm, không chỉ đối với những người theo Đạo mà còn được đón nhận tại rất nhiều quốc gia trên thế giới. Để mừng ngày Thiên Chúa Giáng Sinh, người ta thường ngồi với nhau bên các bữa tiệc, tặng quà, hát mừng và dĩ nhiên là tham dự các buổi lễ kỷ niệm Công giáo. Trong không khí se lạnh mùa đông, chúng ta hãy cùng điểm qua một số thông tin thú vị xoay quanh ngày lễ này nhé.

1. Chọn ngày lễ Giáng Sinh

Tinhte-ngay-giang-sinh.

Vào những buổi ban đầu, Giáo hội Công giáo không tổ chức một bữa tiệc lớn để kỷ niệm ngày Giáng Sinh như hiện nay. Trên thực tế, Kinh Thánh Công Giáo cũng không thực sự đề cập đến thời điểm cụ thể Thiên Chúa ra đời. Các nhà sử học cho rằng Chúa ra đời vào mùa xuân nhằm phù hợp với đoạn Kinh Thánh ghi chép lại cảnh các mục đồng chăn thả gia súc. Theo ghi chép sử học, vào khoảng năm 200 sau công nguyên, các nhà thần học Alexandria đã chọn ngày 20 tháng 5 làm ngày lễ kỷ niệm Chúa Giáng Sinh. Mãi cho đến thế kỷ thứ 4, Giáo Hội Công Giáo đã quyết định công nhận sự kiện Giáng Sinh là một ngày lễ chính thức và Đức Giáo Hoàng Julius I đã chọn ngày 25/12 hàng năm làm ngày lễ mừng.

2. Ai đã phát minh bộ tượng trang trí Giáng Sinh?

Tinhte-tuong-Chua.

Thánh Phanxicô Assisi (Tiếng Ý là Francesco d’Assisi), còn gọi là Thánh Phanxicô khó khăn, là một tu sĩ Công Giáo sáng lập ra Dòng Phan Sinh. Giáo hội xem ông là thánh bổn mạng của loài vật, chim trời, môi trường và nước Ý. Ông là người đã dành suốt cuộc đời cho sứ mạng truyền giáo và được phong thánh vào năm 1228. Một thông tin khác ít người biết đến, ông là người đã phát minh ra bộ tượng miêu tả cảnh Thiên Chúa Giáng Sinh vào thế kỷ 13. Đây là bộ tượng hết sức phổ biến trong ngày lễ Giáng Sinh. Hầu như mọi hang đá được bày dọn, trang trí ngày nay đều có sự xuất hiện của bộ tượng này với Chúa Jesus hài đồng ở giữa, Đức Mẹ, Thánh Giuse,…

3. Nguồn gốc của truyền thống tặng quà quà, thiệp mừng,…

Tinhte-cay-thon-noel.

Tặng quà, gởi thiệp mừng, tiệc tùng và nhiều truyền thống Giáng Sinh đã xuất hiện từ lâu chứ không phải được hình thành gần đây. Nguồn gốc của điều này đến từ thời La Mã cổ đại. Khi đó, người ta trao đổi những thứ nói trên vào ngày mừng năm mới Strenae (đặt theo tên vị thần của những món quà năm mới). Ban đầu, Giáo hội Công giáo không chấp nhận thực hiện những điều này trong ngày Giáng Sinh, tuy nhiên những thói quen cũ đã ăn sâu vào người dân nên vẫn được chuyển sang áp dụng cho ngày Giáng Sinh.

4. Nguồn gốc của Xmas và Noel

Tinhte_Giang-Sinh-201405.

Các nhà nghiên cứu cho rằng trong quá trình chuyển ngữ, các học giả đã dùng chữ chi (ký hiệu là X) trong tiếng Hy Lạp để rút gọn chữ “Christ” (Chúa Jesus, trong tiếng Hy Lạp là Χριστός) và cuối cùng, chữ Christmas sẽ được rút gọn thành Xmass. Điều này có nét tương đồng với sự hình thành của ẩn số x trong toán học, các bạn có thêm xem thêm tại đây.

Theo từ điển Oxford, Noel là một từ Pháp cổ (Nouel). Từ này được viết trong tiếng Pháp hiện đại là Noel và được người Pháp dùng để chỉ ngày Giáng Sinh. Đồng thời, trong tiếng Pháp, người ta sẽ nói “Joyeux Noel” để chỉ “Merry Christmas” hay “Chúc mừng Giáng Sinh”.

5. “Jingle Bell” là bài hát đầu tiên trên vũ trụ

Tinhte-Gemini_6_7.

Vào ngày 16/12/1965, 2 phi hành gia Walter “Wally” Schirra Jr. và Thomas P. Stafford đang trên bay trên quỹ đạo của Trái Đất bằng tàu Gemini 6. Khi đó, họ đã tiếp cận với tàu Gemini 7 đang được điều khiển bởi Frank Borman and Jim Lovell. Đây là lần đầu tiên 2 con tàu không gian gặp gỡ và cách nhau vài mét trên quỹ đạo. Lúc đó, tàu Gemini 6 đang chuẩn bị trở về Trái Đất và họ tưởng đã gặp người ngoài hành tinh do cả 2 tàu đều không biết trước được tình huống này.

Sau đó, phi hành gia từ tàu Gemini 6 đã xác định kỹ hơn, ông nhận ra “vật thể” trước mặt có 1 mô đun chỉ huy với 8 mô đun nhỏ hơn ở phía trước và ông nhận ra đây cũng là 1 phi thuyền. Phi hành gia chỉ huy đang mặc một bộ đồ màu đỏ. Và ngay lập, Walter và Stafford đã dùng kèn harmonica và chuông lén mang theo từ Trái Đất để chơi bài “Jingle Bells”. Sự kiện chớp nhoáng này đã được ghi vào lịch sử ngành hàng không vũ trụ và “jingle Bell” trở thành bài hát đầu tiên được xướng lên trên không gian.

6. Cây thông Noel

Tinhte-qua-noel.

Trước khi Giáng Sinh trở thành ngày lễ Công Giáo chính thức, người Đức đã trang trí những cây xanh quanh nhà họ để đẩy lùi bóng tối và những ngày mùa đông ảm đạm. Khái niệm “Cây Giáng Sinh” xuất hiện tại Strasbourg vào khoảng thế kỷ 17 và bắt đầu được những người nhập cư gốc Đức mang tới Pennsylvania vào năm 1820. Khi nữ hoàng Victoria cưới hoàng tử Đức Albert vào năm 1840, ông đã mang truyền thống “Cây Giáng Sinh” du nhập vào nước Anh. 8 Năm sau đó, tờ báo tại Mỹ đầu tiên đã đăng tải hình ảnh những cây Giáng Sinh hoàng gia Anh và thế là không chỉ tại Pennsylvania mà cả nước Mỹ bắt đầu sử dụng hình tượng này vào ngày Giáng Sinh.

7. Ông già Noel

2668823_Tinhte_Giang-Sinh-201401.

Ông già Noel là một nhân vật dựa trên Thánh Nicholas, một vị Giám mục Nhà thờ Công giáo và được xem như vị thánh bảo trợ trẻ em. Ông ra đời vào thế kỷ thứ 3 (khoảng năm 270 sau CN) tại một ngôi làng thuộc Thổ Nhĩ Kỳ. Ông nổi tiếng qua việc bí mật tặng những món quà hoặc tiền cho người nghèo. Ngày nay, hình ảnh hiện đại của ông già Noel thường đi kèm với bộ trang phục màu đỏ, bộ râu bạc trắng, cưỡi xe trượt tuần lộc và mang theo túi quà đi phát cho trẻ em.

8. Những cây kẹo hình gậy

Tinhte_Giang-Sinh-201402.

Vào những năm 1800, một người làm kẹo tại bang Indiana, Mỹ muốn tạo nên một loại kẹo làm hình tượng trong ngày Giáng Sinh. Cuối cùng, ông đã nảy ra ý tưởng uốn cong 1 thanh kẹo màu trắng thành hình dạng cây gậy. Đồng thời, ông thêm những đường màu đỏ xoay quanh cây kẹo để diễn tả tình yêu và sự hy sinh của Chúa Jesus cho nhân loại. Đầu tiên, ông dùng 1 mảnh kẹo bạc hà màu trắng, phẳng. Màu trắng biểu trưng cho sự tinh tuyền và vô nhiễm nguyên tội của chúa Jesus. Sau đó, ông cho thêm 3 sọc đỏ vào để tượng trưng cho sự đau đớn mà Chúa phải chịu khi Người chết trên thập giá.

Tiếp theo, mảnh kẹo được làm thêm 2 sọc đỏ đậm để biểu thị cho máu của Chúa đã chảy ra vì nhân loại. Và cuối cùng, toàn bộ sẽ được cuốn lại, cắt ngắn thành dạng thẳng và uốn cong 1 đầu theo hình cây gậy. Đây là biểu tượng cho cây gậy mà người chăn chiên dùng để chăn dắt bầy chiên của họ. Và nếu bạn đảo ngược cây gậy lên, nó sẽ trở thành chữ J, nghĩa là Jesus. Và dần dần, loại kẹo này bắt đầu được sử dụng rộng rãi như một trong những biểu tượng của ngày Giáng Sinh.

9. Giáng Sinh trong chiến tranh

Tinhte-Giang-sinh-chien-trah.

5 tháng từ khi chiến tranh thế giới thứ 1 nổ ra, binh lính dọc theo mặt trận phía Tây đã có một đêm mừng Giáng Sinh. Khi đó, dù đang chiến đấu ở 2 chiến tuyến khác nhau, nhưng cả 2 phe vẫn cùng nhau hát các bài hát Giáng Sinh. Sáng sớm hôm sau, những binh sĩ người Đức đã leo lên từ các chiến hào và bắt đầu hướng về phía quân đồng đồng minh để đồng thanh nói lời “Merry Chrirstmass” bằng tiếng Anh. May mắn thay, đó hoàn toàn là những hành động thật lòng và những chiến sĩ người Anh cũng đáp lại bằng cách tiến ra bên ngoài, chào đón và bắt tay với người Đức. Thậm chí, họ còn dùng thuốc lá để làm quà trao cho nhau và cùng chơi đá bóng. Tiếp theo hành động đẹp đó là thỏa thuận ngừng bắn Giáng Sinh năm 1914, một nghĩa cử cao đẹp trong chiến tranh.

10. Giáng Sinh trên khắp thế giới

Tinhte_Giang-Sinh-201404.

Dựa trên nguyên bản ban đầu, ngày Giáng Sinh sẽ được biến tấu theo những cách khác nhau tùy thuộc vào nền văn hóa mà nó du nhập. Tại Phần Lan, người ta thường đi tắm hơi vào đêm Giáng Sinh. Trong khi đó, người Bồ Đào Nha lại tổ chức một bữa tiệc trong đêm Giáng Sinh nhằm cầu cho cuộc sống hiện tại và những linh hồn đã qua đời. Tại Hy Lạp, một số người tin rằng những con yêu tinh kallikantzeri sẽ chạy trong suốt 12 ngày Giáng Sinh và do đó, mọi người sẽ không tặng quà cho nhau cho đến ngày 1/1.

Nhờ vào vị trí địa lý đặc biệt nên phần lớn người Úc và New Zealand thường thưởng thức thời gian Giáng Sinh trên bãi biễn với các bữa tiệc nướng. Tỏng khi đó, tại Tây Ban Nha, người ta sẽ tổ chức sự kiện xổ số lớn nhất thế giới trong ngày lễ này.

Trên đây là 10 thông tin thú vị xoay quanh ngày lễ Giáng Sinh. Giây phút đêm Noel đã cận kề, những bài hát Noel dường như ngày càng vang lên nhiều hơn và không khí cũng nóng lên theo từng phút. Cám ơn các bạn đã dành thời gian theo dõi bài viết. Hy vọng rằng bài viết cung cấp thêm một số thông tin thú vị xoay quanh ngày lễ lớn trong mùa đông này để các bạn có dịp kể cho nhau nghe khi vui chơi Giáng Sinh. Cuối cùng, chúc các bạn có Giáng Sinh vui vẻ và hạnh phúc. Bạn nào có hình ảnh đẹp Giáng Sinh xung quanh thì cũng có thể chia sẻ thêm bên dưới cho mọi người cùng vui nhé. :D

Tham khảo Time, GotQuestion, Thfw, LV, PlayBuzz

[Discovery] Bộ nhớ điện trở RRAM – ứng cử viên sáng giá thay thế cho NAND Flash trong tương lai

RRAM_Design.
Thiết kế bộ nhớ RRAM của Crossbar.

Sau khi giới thiệu công nghệ bộ nhớ điện trở (RRAM hay ReRAM) hồi tháng 8 năm ngoái thì năm nay, công ty công nghệ bộ nhớ Crossbar đã vừa công bố chuyển sang giai đoạn thương mại hóa thiết kế. Điều này cũng chứng minh rằng công ty có thể chế tạo phần cứng với các máy móc sẵn có, qua đó có thể tìm kiếm các nhà sản xuất để đưa bộ nhớ RAM điện trở đến với thị trường.

Công nghệ bộ nhớ RRAM lưu trữ dữ liệu bằng cách tạo ra điện trở trong một mạch dẫn thay vì trực tiếp giữ điện tích. Khi một dòng điện được áp đặt vào một vật liệu, dòng điện sẽ làm thay đổi điện trở của vật liệu. Trạng thái điện trở sau đó có thể đo đạt và kết quả sẽ được mã hóa 1 hoặc 0.

So với bộ nhớ NAND flash, RRAM có nhiều ưu điểm thuộc về bản chất. Bộ nhớ NAND có tuổi thọ giới hạn và giảm dần khi cell nhớ trở nên nhỏ hơn, các điểm (node) xử lý chu trình ghi/xóa cũng bị thu hẹp lại và số lần sửa lỗi yêu cầu ở mỗi node mới cũng tăng dần qua thời gian. NAND có tốc độ truy xuất cao nhưng việc đọc/ghi dữ liệu cũng làm giảm tuổi thọ bộ nhớ. Cho nên các nhà sản xuất bộ nhớ hiện nay đều tập trung cải tiến các vi điều khiển bộ nhớ NAND hoặc giao tiếp hệ thống thay vì hiệu năng cơ bản của NAND.

Crossbar_RRAM.
Đối chiếu kích thước giữa 1 bộ nhớ NAND 8 GB và 1 bộ nhớ RRAM 8 GB, cả 2 đều dùng quy trình 25 nm.

RRAM có thể giải quyết rất nhiều trong số những vấn đề vừa nêu. Không giống như NAND, RRAM không cần được xóa trước khi được ghi và có tốc độ truy xuất nhanh hơn NAND rất nhiều lần. RRAM cũng tiêu thụ ít năng lượng hơn và theo Crossbar thì nếu như NAND cần đến 1360 pJ (picoJoule)/mỗi cell để hoạt động thì RRAM chỉ cần 64 pJ/cell. Thêm vào đó, Crossbar cho biết công nghệ này hỗ trợ lưu trữ 2 bit dữ liệu/cell (tương đương với bộ nhớ MLC NAND) và có thể được chế tạo thành các lớp 3D chồng lên nhau. Ngoài ra, công ty cũng cho rằng công nghệ có thể được sử dụng để làm giảm độ phức tạp của các vi điều khiển – một lợi thế tiềm năng đáng chú ý khi độ phức tạp và chi phí sản xuất bộ nhớ đang ngày một tăng.

RRAM_App.

Tuy nhiên, việc thương mại hóa RRAM dưới dạng phần cứng tiêu dùng vẫn cần thêm thời gian. Trước mắt, công ty đã cấp phép cho các nhà phát triển chip SoC, mạch tích hợp dành cho ứng dụng đặc thù ASIC và mạch lập trình tùy biến FPGA với các sản phẩm mẫu dự kiến sẽ được chuyển giao vào năm 2015. Những ứng dụng đầu tiên được hướng đến sẽ là các hệ thống nhúng và bộ nhớ cấp thấp do nhu cầu dung lượng bộ nhớ không lớn và hoạt động càng tiết kiệm năng lượng càng tốt.

Mặc dù vây, có một điều vẫn chưa thể thay đổi đó là lộ trình dài hạn để thay thế bộ nhớ NAND. Samsung, Intel, Micron là những công ty đã đầu tư hàng chục tỉ đô để sản xuất bộ nhớ NAND và họ dĩ nhiên không có ý định chuyển sang một chuẩn mới ngay lập tức. Các công ty trong ngành công nghiệp luôn tự hào về việc nhanh chóng đón nhận các công nghệ mới nhất, tuyệt vời nhất nhưng sự thật lại rất khác biệt. Hầu hết các sản phẩm thành công trong ngành công nghiệp máy tính đều là những sản phẩm mở rộng, cải tiến từ những thành quả trước đó về khía cạnh hiệu quả chi phí. Việc một sản phẩm mới hoàn toàn vượt lên và định hướng thị trường hiếm khi xảy ra.

Hiện tại, bộ nhớ NAND 3D hay Samsung gọi là V-NAND sẽ dẫn dắt thị trường trong ít nhất là 3 năm tới, từ 2015 đến 2018. Tuy nhiên, điều này không có nghĩ RRAM sẽ không có mặt trong các ứng dụng thương mại và doanh nghiệp. Thực tế cho thấy thị trường đã dễ dàng đón nhận các giải pháp bộ nhớ NAND đắt đỏ để khai thác các chuẩn như PCI Express hay NVMe khi các sản phẩm này có thể mang lại thời gian phản hồi nhanh hơn nhằm đáp ứng cho các ứng dụng yêu cầu về độ trễ thấp. Do đó, RRAM có tiềm năng mang lại thời gian phản hồi tốt hơn và đủ khả năng đáp ứng cho một số lĩnh vực nhất định.

Trước mắt, bộ nhớ NAND 3D sẽ là xu hướng tiếp theo cho ngành công nghiệp bộ nhớ bởi nó cho phép các công ty chuyển sang quy trình sản xuất nhỏ hơn với mật độ node cao hơn. Samsung hiện tại đang phát triển V-NAND trên công nghệ xử lý 40 nm. Tuy nhiên, NAND 3D vẫn là NAND và nó vẫn tồn tại những hạn chế về mặt chức năng dài hạn. Vì vậy, chúng ta cần phải thay thế bộ nhớ flash với những dạng bộ nhớ bền hơn nếu muốn tiếp tục cải thiện mức tiêu thụ năng lượng và hiệu năng xử lý trên tỉ lệ bộ nhớ. RRAM có vẻ như là một tùy chọn có khả năng hiện thực hóa nhất.

Theo: ExtremeTech

[Dev Tip] Understanding Windows Identity Foundation (WIF) 4.5

First things First

If you are looking for an article that shows a lot of code and dissects the new WIF 4.5 APIs, then you won’t find what you need here.

My aim in this article is to explain the “why” and the “what” rather than the “how”. Once you understand that, the “how” becomes really simple. This article does not assume pre-knowledge of the topics of federation, claims, and WIF so it’s suited for beginners. However, I think that mid-level knowledge audience will also benefit from it. If you’re like super-expert, well please contact me to help me in my current project.

What Exactly is the Problem?

Authentication (and authorization) is an ever present challenge for most applications. The challenge that these applications face is the same: authentication logic creeps into the application code and becomes coupled with it; any change to the authentication requirements will result in a change in the application itself.

Say for example that your user store is SQL Server and new business mandates adding an existing Oracle-based user store to your list of users, or maybe you want to mix your authentication to support both custom user stores (SQL Server or Oracle) with Active Directory user store. And what about social media? It’s increasingly popular nowadays for applications to allow authentication via services such as Google and Facebook.

Here is another tough case: assume you used to ask you users for username/password combination to log in. Now based on certain needs, you want them also to supply additional information such as a one-time code. This will certainly lead to UI change for your login page as well as code change.

In all these cases, something has to change in your code. Of course, having a good architecture with a proper separation of concerns will ease up the change. However, the idea is that you still have to manage this authentication logic instead of focusing on the business side of your application.

Claims-based authentication is the architecture that solves this problem.

Claims-based Authentication

Claims-Based architecture allows you to delegate authentication logic into another entity. This entity is a “some” layer which abstracts all authentication related coding and gives your application what it needs: is the user authenticated or not, and some information about the user (called claims or assertions) that lets your application take authorization decisions.

The claims-based architecture defines the following actors:

  • Subject: the entity that needs to be authentication. This can be a user that wants to log in to your application, or a piece of code in your application that wants to access a web service.
  • Relying Party (RP): the application (in case the Subject is a user) or the web service (in case the Subject is application code) that needs to delegate the authentication logic
  • Identity Provider (IP): the entity (that “some” layer mentioned before) that actually holds the authentication logic. The IP talks to the user stores as appropriate and performs actual authentication.
  • Claim: When an IP performs successful authentication, it returns to the RP a set of claims. Claims are statements about the authenticated entity – for example birth date, department, role, etc… – that gives the RP information to take authorization decisions.
  • Token: Claims travel inside a token. Although a token can be a username/password combination or even a simple string such as bearer token in OAuth 2.0; in this context tokens can be either XML-based such as SAML tokens or binary-based such as X.509 certificates.

In addition to the above definitions, WS-Federation and WS-Trust protocols define another term called Secure Token Service (STS). STS is the web service exposed by the IP that provides the authentication service.

Before the claims-based flow can start, the RP and IP need to publish their policies. In abstract terms, a policy is a contract published by an entity that specifies the terms and conditions that other entities must obey before establishing communication.

In this context, the policy published by the IP specifies the supported protocol(s) and security requirements as well as supported claim types. Similarly, the policy published by the RP specifies its own protocol, security, and claims requirements as well as the list of IPs it trusts to delegate authentication to.

The rest of the article discusses WS-Federation (and related WS-standards) and its implementation in WIF, while I will also briefly discuss SAML 2.0.

The WS-* Mania

For some, the WS-* standards are something to avoid. They tend to strike developers as being overly complex. Indeed complex they are. However, with the advent and continuous enhancement of developer libraries, most of the times working with WS-* standards is nothing more than configuration tweaking. Granted however, you always need to understand what is going behind the scenes if you really want to understand the architecture.

This section discusses – briefly – some core WS-* standards that are related to WS-Federation.

WS-Security

WS-Security is a SOAP extension that adds authentication/authorization, message protection, and message integrity to SOAP messages.

  • Authentication/authorization: authentication is implemented using security tokens while claims carried inside a security token aid in authorization. Although can be extended, the three types of tokens you’d usually see are Username, Binary, and XML-based tokens.
    • Username tokens: these are the plain-old username/password combinations sent in the SOAP header. Verification of identity can be achieved by hashing the password or applying a digital signature.
    • Binary tokens: these usually come in two flavors: X.509 certificates and Kerberos tickets.
      • X.509 certificates: an X.509 certificate is the public key container of a public/private key pair. Obviously since it contains a public key it cannot be relied upon for authentication by itself. The certificate is signed with the private key portion of the sender. The receiver uses the public key to verify the signature. Since the private key is unique for the sender, signature verification proves identity
      • Kerberos tickets: if a Kerberos infrastructure is already in place, WS-Security recognizes Kerberos tickets as a valid security token type
    • XML-based tokens: XML tokens were published as an ad-on specification to WS-Security. XML tokens contain a set of claims about the sender. Similar to X.509 certificate tokens, XML tokens must be accompanied by a signature generated by the sender so that the receiver can verify its identity. Probably the most dominant form of XML tokens is SAML token.
  • Message protection: Whereas at transport level message protection is established using SSL, at message level this is done via XML Signatures. Depending on the configuration, WS-Security uses either a symmetric shared key or an asymmetric public/private key pair to encrypt the required message content. In the symmetric approach the shared key must be exchanged securely prior to communication. In the asymmetric approach the sender encrypts the (required) message content using the receiver’s public key and the receiver decrypts it using its private key. Most of the time though, the approach used is a combination of both due to the fact of asymmetric approach being compute-expensive. In this hybrid approach, asymmetric encryption is used to exchange a shared key and then this shared key is used for encryption for the rest of the session communication.
  • Message Integrity: as discussed in the authentication section, XML signatures are used to establish user identity. It is also used to establish message integrity; i.e. that the message has not been tampered with. By attaching a signature with a message, the receiver recalculates the signature and verifies integrity if both signatures match. Similar to encryption, a hybrid approach is usually used to reduce the cost of asymmetric-based signatures.

WS-Policy

WSDL does a good job describing basic web service requirements such as message schemas and authentication headers. However, WSDL cannot describe contractual requirements such as security. For example, recall form the previous section of Claims-based architecture, that an RP-IP interaction is governed by a set of security policies. These policies cannot be described using WSDL; instead they are described by WS-Policy and its related specification WS-SecurityPolicy.

In general, there are WS-Policy assertions for security, reliable messaging, sessions, transactions, reliable messaging, among others. In WCF, these policies are specified either as code attributes or configuration sections.

  • WS-Policy: a specification that defines a framework for describing policy assertions. An assertion is a requirement or preference of the service. This specification defines a common language regardless of the assertion domain (security, transactions, reliable messaging, etc…).
  • WS-PolicyAssertion: a specification that defines general messaging-related assertions for use with WS-Policy. Separate assertions exist for different domains; for example, WS-SecurityPolicy, WS-AtomicTransactions, and WS-ReliableMessaging.
  • WS-PolicyAttachment: a specification that describes how policies are attached to WSDL (and UDDI).

WS-Addressing

WS-Addressing specification provides elements that enable end-to-end transport-independent message transmission. For example this allows you to implement message routing (previously WS-Routing) where – based on some message criteria – you can explicitly specify the next hop in the message route. Also some of the other things that you can do is specify a different response or fault return URLs to a message and thus sending the response to a different endpoint than the originator.

WS-Trust

As discussed in the claims-based architecture, you can delegate your application authentication logic to another entity which issues claims that your application. The part I skipped is how to make your application “trust” these claims? What prevents a fake IP from generating a claim and sending it to your application which then will grant him access?

Let’s take this one step further: assume two companies A and B want to conduct business. Company A want company B users to access its application. How can this be done? One way is for A to provision B users; however, this clearly is a troublesome solution as A will have to manage and control B users. Wouldn’t it be a much better solution if we make A “trust” B users without actually managing them?

WS-Trust is a specification that tackles the above two scenarios. WS-Trust introduces the concept of a Secure Token Service (STS), which is a web service that is responsible of generating claims that are trusted by consumers. In the first scenario (authentication delegation), you have your application establishing a WS-Trust relationship with an STS service for an IP. In this second scenario (companies A & B), both parties establish a WS-Trust where A trusts an STS for B IP; this way B users can carry tokens issued by their IP-STS and present these tokens to A, which trusts the STS and thus grants access.

WS-Trust defines a message request called RequestSecurityToken (RST) issued to the STS. STS in turn replies via a response called RequestSecurityTokenResponse (RSTR) that holds the security token to be used to grant access. WS-Trust describes the protocol for requesting tokens via RST and issuing tokens via RSTR.

WS-SecureConversation

WS-SecureConversation specification provide a mechanism to improve a service response time when the client engages with a lengthy communication with that service.

When a client sends a message to a secure service, part of the request will be dedicated to credential negotiation and authentication. At transport level, this is accomplished in SSL handshake process so any consequent requests use the secure session already established. WS-SecureConversation achieves the same on the message level.

WS-SecureConversation specification states that the client first sends an RST (from the WS-Trust specification) to the service. The service validates the credentials within the RST and issues back a token called Secure Context Token (SCT) with a symmetric key to perform the cryptographic operations for the remaining communication.

These tokens are used by WS-Security for authentication and integrity and are described at both ends (IP & RP) using the WS-SecurityPolicy assertion.

WS-Federation

So we’re finally at the WS-Federation section! All the previous specifications discussed lead to this place.

Let’s start by defining federation: Federation refers to multiple security domains (also called realms) – typically multiple organizations in B2B scenarios – establishing trust for granting access to resources. Carrying on with the terminology we have been using, an RP in domain A can trust an STS IP in domain B so that B users can access resources of A.

WS-Federation build on WS-Trust and simplifies the creation of such federated scenarios by defining a common infrastructure for achieving federated identity for both web services (called active clients) and web browsers (called passive clients).

WS-Federation says that organizations participating in federation should publish communication and security requirements in Federation Metadata. This metadata adds federation specific communication requirements on top of the WS-Policy (and WS-SecurityPolicy) metadata described before. For example, token types and single sign out requirements are examples of what is defined in the Federation Metadata.

WS-Federation does not mandate a specific token format, although as we will see later, SAML tokens are used heavily.

Identity and Access Control in .NET 4.5

Identity and Principal pre-.NET 4.5

If you have been creating applications in .NET framework since v 1.0, chances are you have already came across interfaces IIdentity and IPrincipal. IIdentity would represent the identity of the authenticated user while IPrincipal contains that specific identity in addition to a method to check if the user is a member of a certain role.

Different implementations existed for IIdentity and IPrincipal:

  • WindowsIdentity and WindowsPrincipal are used for windows, active directory, or Kerberos authentication
  • GenericIdentity and GenericPrincipal are used for custom authentication such as forms authentication

As you can see, role-based access (or authorization) up until .NET 4.0 was really restricted to the IsInRolemethod of the IPrincipal and its implementations. There are multiple ways to call this method; you can call it directly via the API, or you can use attribute-based authorization (PrincipalPermission), or you can use the authorization element in the web.config. Regardless of the method, your role-based access power was limited to checking if the logged in user belong to a certain group or not.

Now if you have reached so far in this post, you will for sure have noticed that claims-based authorization gives you much bigger power. Using claims you can make access decisions based on things like a user birth date, national id, and of course roles, among others. The idea is that the system that performed authentication (the IP in our literature) attaches any attributes agreed with the RP as a set of claims (assertions); the RP then uses these claims to make suitable authorization decisions.

So are claims not supported pre-.NET 4.5? Yes they are, and here’s how:

WCF 3.0 Claim Transformation

Before Windows Identity Foundation (WIF) 1.0 was shipped, Microsoft’s first attempt to incorporate claims into their security model came under the umbrella of WCF. In WCF 3.0 Microsoft included the System.IdentityModel assembly which basically generated a set of claims for every security token authenticated by WCF. WCF 3.0 shipped with the following classes:

  • System.IdentityModel.Claims.DefaultClaimSet, which represents any additional generic claims sent to the service
  • System.IdentityModel.Claims.X509CertificateClaimSet for converting X509 tokens to claims
  • System.IdentityModel.Claims.WindowsClaimSet for converting Windows tokens to claims

WCF 3.0 included authorization policies to perform the actual claim transformation.

The problem in this approach was that now .NET developers have two completely different security infrastructures for web applications (IIdentity and IPrincipal) and for WCF services (System.IdentityModel). So if you have an application which consists of both web app and web service, then you’ll have to write nearly the same code twice against two different libraries.

WIF 1.0

Microsoft enhanced their claim infrastructure in In WIF 1.0. Instead of the System.IdentityModel used in WCF 3.0, they shipped a new assembly of name Microsoft.IdentityModel.

The need to support claims was achieved by adding another implementation of IPrincipal, calledIClaimsPrincipal which will be populated once claims-based authentication is used. As you can see, this way WIF combined both worlds: that of base classes IIdentity and IPrincipal and that of WCF 3.0 claims infrastructure.

Here is how you would retrieve claims for a claims-authentication enabled application:

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;
string email = (from c in identity.Claims where
   c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email
   select
   c.Value).Single();

As you can see, we’re casting the current principal’s identity to get the IClaimsIdentity.

Now even with this improved approach, can you already spot the drawback? Well the issue here is that with this approach if you use WindowsPrincipal or GenericPrincipal you won’t get claims as IClaimsPrincipal is just another implementation of IPrincipal much like the other two. It’s either this or that. This makes claims support in .NET 4.0 not a first class citizen.

Identity and Principal in .NET 4.5

In .NET 4.5 claims are made available regardless of the authentication type. What Microsoft did was creating a new implementation of the base IPrincipal, called ClaimsPrincipal. Then they made every other principal (WindowsPirincipal and GenericPrincipal) derive from ClaimsPrincipal, and they removed theIClaimsPrincipal of .NET 4.0. This way, you will get claims all the way; for example even if you use forms authentication, all the attributes you pull from a membership provider will be carried in claims.

This way, role based access is unified for all authentication types and more important, it’s much richer than the simple IsInRole approach because you now depend on claims to take decisions.

Let’s see how you can retrieve claims for a claims-authentication enabled application and compare this to the same code you had to write pre-.NET 4.5:

string email = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Email).Value;

ClaimsPrincipal.Current basically plays the same role that Thread.CurrentPrincipal used to play.

Let’s see the new claims-based model in .NET 4.5. Below you can see the debugger of a VS 2012 web application using WindowsIdentity:

You will notice that the base class is of type System.Security.Claims.ClaimIdentity which as explained is the new base class for the identity classes as of .NET 4.5. Also notice how although we used windows identity, claims are populated with windows login specific information. In .NET 4.5, you will get claims no matter what.

The below figure shows a similar result when we define a GenericIdentity (simulating a forms authentication for example). Again the base class is common and a claim of type name is generated by default:

When using forms authentication, you will get the Name claim by default. You can get additional claims by using the ASP.NET Role Manager.

Let’s briefly discuss some more concepts and capabilities of .NET 4.5 claims model.

Supported Credential Types

As discussed before, the biggest advantage of the claim model is that regardless of the authentication mechanism used, your application will always rely on claims to achieve authorization. So your application logic does not really care about the actual type of the security token that was used for authentication; authentication logic is a separate concern with its separate module, your application gets claims and you use these claims to take authorization decisions.

Now this authentication layer I am talking about, can be part of your application itself living in a separate module, or – as discussed in the very beginning – can be a separate STS that your application trusts in the IP/RP model. In this discussion our focus is on .NET 4.5 so authentication will be part of the application, the next section dives into WIF 4.5 where you will see STS in action.

So, you .NET 4.5 application can use any of the following security tokens:

  • Windows/AD/Kerberos
  • Forms authentication
  • Client certificates
  • SAML tokens
  • Other extended token types

Once the authentication layer is passed, your application will get claims in the ClaimsPrincipal shown before.

Claims Transformation

Before the claims actually hit your application, it can be subjected to a transformation/validation layer. Once example of transformation need is that you know claims will come is a certain format and you would like to change this format to suit your application coding. An example of validation is – say your application accepts claims from an STS – and you want to make sure before handing the claim to your code that the minimum set of required claims are actually present.

To implement this transformation/validation, you will have to override a class calledClaimsAuthenticationManager.

Authentication Sessions

The logic you wrote in the ClaimsAuthenticationManager derived class can be run at each and every request, or you have the option to cache its outcome if you believe its logic is expensive. The cached value can be saved in cookies for ASP.NET applications and using WS-SecureCoversation for WCF services.

Claims-based Authorization

Finally we are the stage of actually performing authorization decisions based on the claims. The classClaimsAuthorizationManager is what you’d want to derive from to implement your authorization logic. This class contains the method CheckAccess which can be called whenever you want to make an authorization decision.

This way you won’t mingle authorization logic directly into your business logic (which typically was the approach used in the days of the IsInRole checking).

Once again, I want to remind you that this approach of using claims inside your application is the same regardless if whether the claims are generated by authentication logic as part of your application or if the claims are given to your application by an STS that it trusts. In both cases, you have the ability of using theClaimsAuthorizationManager to minimize the coupling between your business logic and the authorization decision.

One final note: the claims-based model is the same for web applications and WCF services. So the .NET 4.5 code to retrieve, transform, and authorize claims works the same regardless of whether the consumer is a .NET 4.5 web app or WCF service.

Windows Identity Foundation (WIF) in .NET 4.5

In the previous section I discussed the claims model in .NET 4.0 vs. .NET 4.5 and showed you how claims are now first class citizens in .NET 4.5. However, the previous section still used the “traditional” authentication mechanism where authentication is still your application’s responsibility. Be cautious though, I do not want the previous section to deviate your attention from the main focus of this article: delegating authentication responsibility to an external entity.

WIF is Microsoft’s technology for encapsulating the inner workings of WS-Federation (and WS-Trust) behind a .NET library which makes it easy for developers to create claims-based apps without the need to know the details of the specs we discussed previously.

As was discussed in the previous section, we have seen how identity and access support in .NET passed through multiple stages, from the simple IsInRole checking, to claims support in WCF 3.0, to WIF 1.0 and then to .NET 4.5.

WIF 4.5 is where this ends (and the new work begins!). In .WIF 4.5, Microsoft did yet another naming change to the assemblies:

WIF in Action

VS 2012 provides you with the tools to quickly set up your RP and use a local STS. Creating an STS should be really the last thing that you would try to do. However, you will only use this STS for development/testing purposes. Running an STS is not a simple task as its business critical and relies on complicated protocols and cryptographic operations.

STS commercial products are available and you are likely to use them. Some of these products are:

  • Active Directory Federation Services (ADFS) v2
  • IBM Tivoli Federation Manager
  • Oracle Identity Manager

ADFS v2 is the topic of the next article.

So why does Visual Studio give you this local STS? Simply to aid you during the development (and possibly testing) phase where the STS product might not be accessible to you. Since your RP does not hold the authentication logic anymore, all what you have to do before going to live is to edit the policy for your RP to trust the new STS instead of the one created using visual studio.

Let’s roll.

Create a new VS 2012 ASP.NET 4.5 web forms application. Right click the project and select “Identity and Access”. This will display a wizard giving you three options: ADFS2 and ACS will be discussed in future posts, I will just quickly note that ADFS2 is the STS of AD and ACS is the STS on Azure.

Select the option to create a local STS. In the Local Development STS tab, you can select the SAML token version to use, the local port of the STS, but most important you can select the claims that the STS will give your RP. In WIF 1.0, you had to manually edit the local STS code to change the set of claims; this way is much cleaner and true to the promise of isolating you (the RP owner) from the authentication logic. Notice that you can use from the many pre-defined claim namespaces and you can define your own. Accept the defaults to close the wizard.

VS 2012 has now equipped your RP to trust a local STS and set up the policy between them. To see this, let’s examine the web.config of the RP:

  • Forms Authentication removed: your RP now is neither windows nor forms authentication-base. It is a claims-based application, so forms is disabled because forms is the default when creating a VS web forms app.
  • Two HTTP modules that makes WIF magic possible:
    • WSFederationAuthenticationModule: this module intercepts incoming requests and redirect unauthenticated ones to the trusted IP(s). For authenticated requests it processes claims within the security token and presents them to your application in a consumable format.
    • SessionAuthenticationModule: this module takes care of session management after an authentication is established. The WSFederationAuthenticationModule module is bypassed andSessionAuthenticationModule handles requests until the session is expired or a sign-out flow is invoked.
  • audienceUris: lists the URIs that your RP will consider valid for the received tokens
  • trustedIssuers: the list of trusted IP certificates that the RP will accept signatures from to verify the token
  • wsFederation: configures the WS-Federation protocol, such as using the passive protocol flow, the IP that the protocol will talk to, and the realm which is basically the ultimate return-URL that the protocol flow will end up in – the RP itself in this case.

In addition, VS 2012 has created a FederationMetadata.xml file in the RP solution. Recall from the discussion of WS-Federation that organizations participating in federation should publish communication and security requirements in Federation Metadata. This XML file holds these requirements for this RP.

Now run the application, quickly notice the browser navigation and you will see that your application gets redirected to the local STS which performed the (hardcoded) authentication and returned back to your application as an authentication user (assume you’re Terry for a moment!). You can now access the claims inside your application just like we have seen before.

Now let’s see what happened in the background to examine WS-Federation and the supporting protocols discussed before in action. To do so, I will use Fiddler:

Step 1: A user browses the RP

You asked for the application via the browser. The WIF HTTP module WSFederationAuthenticationModuledetects that you are not authenticated, so it redirects the browser back with a 302 response and with a Location header that contains the address of the IP-STS at which you must authenticate. In addition, a set of WS-Federation protocol query strings are also supplied to govern how the flow will behave:

  • wa: with a value of wsignin1.0 which means that this is a sign in request (note that WS-Federation also supports sign out flow, so this parameter is mandatory)
  • wtrealm: this is the RP itself, and it represents the intended consumer of the token
  • wct: this is an optional parameter that specified the time of the response of the RP. This might be used as indication to possible attacks if the IP sees that there is a time lag between this parameter value and the actual time it received the sign in request

Step 2: The browser sends a GET request to the STS

The browser then uses the STS address in the Location header and the query strings discussed before to assemble a sign in request to the STS. Here is the request made to the local STS:

Step 3: The IP-STS performs authentication

In “real” scenario, the STS will normally present you with an authentication form that you would supply your credentials to. This procedure of STS authenticating users – as mentioned before – is outside the scope of WS-Federation and thus WIF. The STS can authenticate you against an AD, a custom user store, or even using an X.509 certificate. This depends on the type of the RP application and where the users are coming from. Regardless of the mechanism to authenticate, the STS will – assuming successful authentication – generate a security token containing the claims agreed between the IP and RP via policy.

Step 4: The STS sends the response back to the browser

The STS sends back to the browser a hidden form with will POST back to the RP. The form contains the following information:

  • wa: same as before indicating a sign-in flow
  • wresult: contains the SAML security token issued by the STS.

If you carefully examine the response, you will see many of the protocols discussed before coming into play:

  • The RequestSecurityTokenResponse (RSTR) of WS-Trust carries the token collection
  • XML Signature of WS-Security is used to provide message integrity and trust between the IP and RP
  • WS-Policy – driven by the Federation Metadata – indicates rules such as token lifetime
  • WS-Addressing is used to identify the endpoint reference for the passive request (i.e. the RP)

I reformatted the content for ease of display, here you can see these protocols in action:

Note: There is a difference between SAML-P (the protocol) and SAML token. SAML-P is a full blown protocol much like WS-Federation. SAML token is a token type that can be used independent of SAML-P, and it’s one of the token types frequently used in WS-Federation.

I will briefly touch on SAML-P 2.0 at the end of this article. 

Step 5: The browser posts back to the RP

The browser uses the hidden post form from the previous step to post the result shown in the previous step back to the RP

Step 6: The RP verifies the token

Verifying a token involves multiple checks that could take place based on each situation and policy. Some of these checks are:

  • Integrity: in case digital signature is used, the RP uses the IP public certificate included in the request to verify that the digital signature is valid
  • Expiration: in case an expiration for the token is present, the RP verifies that the token is not expired
  • Decryption: in case encryption is used, the RP uses its private key to decrypt the contents. In the above example, encryption was not used as we were in the passive (web browser) case, later I will discuss the active case and illustrate the difference.
  • Source: using the policy, the RP makes sure the token is issued by a trusted IP
  • Claims: also using the policy, the RP checks that the set of claims issued are the ones agreed on

Step 7: A session cookie is issued

Once the token is verified, the RP issues a session cookie back to the browser so that next requests do not pass through the same WS-Federation process.

WIF for Active Clients

The browser-based scenario we have just seen is called a passive scenario. Passive clients are those that do not possess the WS-* capabilities. Browsers are passive because they just perform redirects they are told to, but by themselves browsers have no notion of WS-Federation.

Another type of clients are active ones. Active clients are those that can perform WS-* operations; an obvious example are WCF services. A WCF service can also act as a claims-based enabled RP. In this scenario, the client (the Subject as per the defined terminology) is an application calling the WCF service which requires claims-based authentication from a trusted STS.

The full cycle goes as follows:

  • An application reaches a line where it is invoking a WCF service. The WCF service itself is an RP configured for claims-based authentication.
  • The WCF client library at the application finds out that the WCF service needs a security token to grant access. The library then issues an RST to the STS.
  • The STS replies back with a security token via RSTR
  • The client application then uses this token to access the WCF service. Now here you can spot a major difference between the passive and active scenarios. Recall in the passive case that the client (browser) had only Https as option for encrypting its request to the RP – called transport level. In the active case, the client (application) can actually use the token to perform custom message level encryption on the message. Message level security has the benefits of better performance as we can be selective for which parts of the message are deemed sensitive and thus to be encrypted and it also supports end-to-end messaging.

The good news is that when it comes to WIF, you do not have to learn anything new than what you saw in the passive case. The same programming model applies. Again you can right click a WCF project in VS 2012 and configure it as an RP using the “Identity and Access” wizard. The defining difference between active and passive clients becomes clear when you inspect the web.config of the WCF service; you will see the ws2007FederationHttpBinding in use, which again shows you that active clients are WS-* aware.

Federation Providers

So far the discussion has been centered on one role that STS can play, and that is issuing claims on behalf of an IP; and thus it has been called an IP-STS. However, an STS can play another roles; the role of a Federation Provider.

Let’s recall the scenario I discussed before of the two companies A and B wishing to enter a federated business agreement. In that scenario I gave an example of B users needing to access a (single) application in A and how that application is configured as an RP for an STS in B.

Now let’s extend the scenario a bit: instead of B users wanting to access a single application in A, both companies want to extend their partnership and now B users must be able to access multiple A applications. Under the role of IP-STS we have discussed so far, every A application must establish trust with B IP which in turn must provision every A application.

A far better solution is for A to expose a Federation Provider. A Federation Provider is a Resource STS (R-STS) that sits on the resource side (on the relying party side – A domain in this case). Company A applications then establish trust with the R-STS and B then provisions this STS only.

A typical flow will then goes as follows:

  • An employee on B domain tries to access an A application
  • A detects (via WIF for example) that the user is not authenticated and redirects the request to the STS it trusts; in this case it’s the R-STS on A’s domain
  • In its turn, the R-STS is configured to accept tokens from B IP, so the request is redirected back to B IP
  • The user authenticated herself again B IP using any mechanism defined by B
  • A request is submitted to the R-STS on A containing the token
  • R-STS processes the request and typically does one of 3 things:
    • Issue claims exactly as they were sent from B IP. Here the R-STS decides that the included claims satisfy A application needs
    • Modify claims based on some rules, for example to satisfy special formatting needs for A applications
    • Add new claims that the R-STS knows are important for A applications yet B IP had no information about. For example R-STS might maintain some information from previous transactions for a specific user.
  • The resulted token is then sent to the originally request A application which grants access

Once again, using WIF you can create your own local R-STS; although as explained before, in real scenarios you would go with commercial products. ADFS v2 is also suited to play the role of R-STS; for example its claims-transformation language is ideal for claims modification. Another great example is Azure Access Control Service (ACS) which also plays the role of a Federation Provider on the cloud.

Both ADFS v2 and ACS will be discussed in future articles.

SAML 2.0

I will close this article by briefly addressing SAML 2.0. Please note that I have never implemented this protocol myself, rather what I present here is a summary answer for the common question of WS-Federation vs. SAML just to get you going; but you’ll have a lot of reading to do if you want a definitive answer.

SAML 2.0 consists of two parts; a protocol (much like WS-Federation) that defines interactions and supported communication protocols, and a token format – conveniently called SAML token. The token specification is separate from that of the protocol, so you can use the token in another protocols. Actually that is what we have been doing in this article all along by using SAML tokens to carry claims in the WS-Federation protocol.

From a very high level point of view, SAML 2.0 protocol (SAML-P) achieves the same objectives of WS-Federation: it allows business partners to enter a federation agreement and allows delegation of authentication logic from an application (Service Provider) to an external entity (Identity Provider). The Identity Provider creates a SAML assertion that the Service Provider then validates to grant authentication. The SAML assertion is a SAML token containing claims.

SAML specification is actually divided into multiple parts:

  • SAML core: this specification defines the structure of the SAML assertions and the supported protocols. You can think of this as the base of every other specification
  • SAML bindings: each of the protocols described in the core specification is detailed in the binding specification where each binding has certain communication and formatting requirements
  • SAML profiles: the profiles specification puts together the different specification into a usage profile, such as the login and logout profile.
  • SAML metadata: this specification is basically what makes SAML-P tick. It defines the agreement requirements between the Service Provider and the Identity Provider to establish SAML-P (supported bindings, certificates, cryptography, etc…). Basically this is to SAML-P what WS-Trust is to WS-Federation.

WIF does not support SAML-P, although some time ago an extension to WIF that adds SAML 2.0 support was CTP’ed but has not took off since then. Here you can see the announcement:

http://blogs.msdn.com/b/card/archive/2011/05/16/announcing-the-wif-extension-for-saml-2-0-protocol-community-technology-preview.aspx

It’s not all bad however, ADFS 2.0 however fully supports SAML 2.0 protocol. Why is this great news? Well simply because of the range of interoperability scenarios that is now possible between two environments one adopting WS-Federation and the other SAML-P. So organizations that have already a SAML-P-based protocol infrastructure in place, does not need to change in order to be interoperable with an ADFS-based one.

[Discovery] Con người chịu lạnh được đến giới hạn nào?

2653954_Tinhte-nhiet-do-am.

Không khí lạnh đã lan tỏa tại khắp mọi nơi, không chỉ ở nước ta mà còn ở khắp mọi nơi trên thế giới. Hiện tại, Hà Nội đang là 16 độ C, California (Mỹ) đang 10 độ, Adadyr (Nga) thì nhiệt độ đã xuống tới âm 24 độ C. Một người bạn của mình tại Pháp cũng cho biết là nhiệt độ chỉ còn có 5 độ C và cô ấy bảo “đang lạnh sắp chết rồi!”. Câu nói của cô ấy làm mình tự hỏi con người chịu lạnh được tới bao nhiêu? Và ở mức nhiệt độ nào thì con người sẽ chịu không nổi nữa? Khi nhiệt độ hạ thấp thì cơ thể người sẽ chịu những tổn thương nào? Mời các bạn cùng mình tìm hiểu nhé.

Các cơ chế “tích hợp sẵn” trong cơ thể người để chống lại cái lạnh

Trên thực tế, cơ thể của chúng ta thật sự kỳ diệu, dường như tạo hóa đã chuẩn bị sẵn cho chúng ta các phương án để đối phó với sự khắc nghiệt của môi trường. Và đối với cái lạnh, cơ thể đã được “tích hợp” các cơ chế để bảo vệ tính mạng chúng ta.

Tinhte-co-gian-mach.

Ngay khi những cơn gió lạnh táp vào mặt, cơ thể chúng ta sẽ tự phản ứng bằng cách chuyển máu tránh xa da cũng như các bộ phận nhô ra bên ngoài như ngón tay, ngón chân và chuyển lượng máu đó vào khu vực trung tâm của các cơ quan này. Quá trình này được gọi là sự co mạch (vasoconstriction) và nó giúp giới hạn lượng nhiệt thất thoát ra ngoài môi trường.

Phản ứng thứ 2 từ cơ thể là run lên. Ngay khi nhiệt độ hạ xuống, một số người sẽ bắt đầu rùng mình, nổi da gà, răng đánh vào nhau và tiếp theo đó là rung bần bật lên. Thật ra, khi cảm nhận được cái lạnh, “cảm biến” sẽ gởi tín hiệu về não và não sẽ đáp ứng bằng một loạt những cảnh báo. Sự run rẩy là một trong những cảnh báo đó. Lúc này, cơ bắp của con người sẽ co giãn liên tục. Một cách nôm na, phản ứng này giúp cơ thể tạo thêm nhiệt độ, làm thân nhiệt tăng lên đồng thời cảnh báo cho con người biết rằng “đã đến lúc tìm nơi ấm áp hơn rồi đó.”

2 cơ chế trên được biểu hiện qua nhiều phản ứng khác, các bạn có thể theo dõi thêm tại bài viết “những phản ứng của con người khi gặp thời tiết lạnh.” Nhưng nếu các cảnh báo đã được não bộ đưa ra, nhưng chúng ta không thể tìm được nơi ấm áp để trú ẩn và cơ thể phải tiếp tục ở trong môi trường nhiệt độ thấp thì sao?

Tổn thương trước khi “đóng băng”

Tinhte-tuyet.

Dưới góc độ y học, khi nhiệt độ trung tâm (core temperature) của cơ thể hạ xuống thấp, cơ thể bắt đầu xuất hiện hạ thân nhiệt (hypothernmia). Hạ thân nhiệt từ trung bình đến nặng xảy ra khi thân nhiệt xuống dưới 32,2 độ C. Đây là một tình trạng lâm sàng của nhiệt độ dưới mức bình thường, lúc cơ thể không còn khả năng sinh nhiệt để duy trì các hoạt động bình thường. Và nếu cơ thể vừa chịu lạnh, lại bị ướt thì câu chuyện lại hoàn toàn khác. Cơ thể ẩm ướt sẽ mất nhiệt nhanh gấp 25 lần so với trong không khí.

Theo giáo sư John Castellani, trưởng khoa thân nhiệt và môi trường vùng núi tại Viện nghiên cứu môi trường quân y Hoa Kỳ cho biết nhiệt độ trung tâm bình thường của cơ thể người là 37 độ C và hiện tượng hạ thân nhiệt nhẹ sẽ xuất hiện lúc thân nhiệt xuống còn 35 độ C. Và nếu tiếp tục xuống nữa, tình hình sẽ tiến triển theo hướng xấu.

  • Thân nhiệt tại 32,2 độ C, cơ chế bù trừ bắt đầu suy giảm, trạng thái tâm thần có thể biến đổi và thậm chí, bạn có thể bị mất trí nhớ.
  • Thân nhiệt tại 27,7 độ C, bạn bắt đầu mất ý thức
  • Thân nhiệt xuống dưới 21 độ C, trạng thái hạ thân nhiệt nặng diễn ra và con người sẽ chết.

Kỷ lục ghi nhận thân nhiệt thấp nhất của một người trưởng thành từng được biết đến là 13,7 độ C. Lúc đó, người này đã bị ngâm trong nước lạnh và đóng băng trong thời gian khá lâu.

Các thương tổn nguy hiểm do nhiệt độ thấp

TInhte-ton-thuong-lanh.

Chưa đến mức phải chết, nhưng các tổn thương do lạnh giá gây ra cũng không kém phần nguy hiểm. Giáo sư John Castellani cho biết: “Nếu như nhiệt độ trung tâm của cơ thể phải mất khá lâu thì mới giảm xuống, thì nhiệt độ khu vực ngoại vi lại giảm xuống khá nhanh chóng.”

Các ngón tay, ngón chân sẽ dễ bị tổn thương do lạnh giá nhất do các khu vực này sẽ bị giảm lượng máu lưu thông trước tiên khi nhiệt độ hạ xuống. Thậm chí, mặc dù chúng ta có thể đeo găng tay hoặc mang tất nhưng nhiệt độ ngón tay, ngón chân vẫn sẽ rất thấp và nếu bạn lại bị đổ mồ hôi, sự ẩm ướt càng làm cho khu vực này bị mất nhiệt nhiều hơn.

Tuy nhiên, nhiệt độ không khí vẫn còn trên 0 độ C thì các tổn thương do lạnh giá vẫn chưa diễn ra. Theo các nhà nghiên cứu, những tổn thương thường xuất hiện khi nhiệt độ môi trường xuống dưới điểm đông 0 độ C. Castellani cho biết: Nếu bạn phải chịu những cơn gió lạnh âm 9,4 độ C trong thời gian dài thì sự tê cóng nặng sẽ xuất hiện và các thương tổn do lạnh giá mới tăng lên.”

Đồng thời, việc “quãng thời gian” để các tổn thương xuất hiện thì còn phụ thuộc vào các điều kiện môi trường. Ví dụ nếu nhiệt độ môi trường đang là âm 17,8 độ C và những cơn gió rét âm 28,3 độ C, bạn sẽ chịu các thương tổn do giá rét sau 30 phút đứng trong môi trường này. Tuy nhiên, thời gian này sẽ chỉ còn có 5 phút nếu bạn đứng trong môi trường âm 26 độ C và những cơn gió rét âm 48,3 độ C thôi liên tục.

Dù vậy, theo Castellani thì mặc dù những nguy cơ khá cao, nhưng con người có thể ra ngoài trong nhiệt độ môi trường cực kỳ lạnh và vẫn có thể sinh tồn. Bằng chứng là những người leo núi hoặc thám hiểu bắc cực,… Đồng thời, chúng ta đã có những người bơi qua eo biển Manche khi nhiệt độ nước rất thấp. Tuy nhiên, không phải khả năng chịu lạnh của mỗi người là như nhau, có thể những người này phải trải qua quá trình luyện tập trong thời gian dài để cơ thể dần thích ứng với nhiệt độ lạnh. Khi đó, cơ thể sẽ hình thành khả năng sản xuất và duy trì thân nhiệt hiệu quả hơn so với người bình thường.

Do đó, đừng nên mang cơ thể ra thí nghiệm khả năng chịu đựng nhiệt độ thấp. Bạn vẫn có thể mắc bệnh và chịu nhiều thương tổn do thời tiết lạnh giá gây ra nếu không được rèn luyện trước. Nếu vậy, hãy tự giữ ấm và nhắc nhở mọi người xung quanh cũng làm vậy để có được mùa đông tuyệt vời và nhiều sức khỏe nhé. Cám ơn các bạn đã theo dõi bài viết. Hy vọng rằng bài viết đã cung cấp cho các bạn thêm một số thông tin thú vị về mua đông của chúng ta. Có thể đọc đến những dòng này thì điện thoại hay tablet của các bạn cũng đã đủ nóng lên để sưởi ấm cho bàn tay các bạn rồi đó. Chúc các bạn có mùa đông ấm áp bên áo lạnh hoặc người thân nhé. Chúc vui vẻ.

Tham khảo BBC, LS

[Dev Tip] 5 Internal things that you should know about IIS Express

#1 : Where does the basic configuration information stored ?

The basic information related to the IIS Express are stored inside the project file (proj file)  within the property group information section.  To view it, Open the Project File in edit mode ( In this case I will strongly recomand you to use Visual Studio productivity Tool ) ; where you can edit the project file using “Power Command” as shown in the image below.

EditProjectFilesusingPowerCommands thumb 5 Internal things that you should know about IIS Express

Once you have the  project file in edited mode, you can search for below configuration section, where you can see the application information related to IIS Express are set.

IISExpressSettings thumb 5 Internal things that you should know about IIS Express

You can change the configuration editable values and update the project files to take the changes effects.

If your application has the SSL Enabled, IISExpressSSLPort will have the values specified for the SSL  port number.

IISPortEnabled thumb1 5 Internal things that you should know about IIS Express

#2 : Where is the configuration settings related to bindings and virtual directory?

Project files have the information related to the IIS Express and it’s basic settings; whereas there are several configuration files that are required to host and run a web application.  You can find all the IIS Express related files under \users\<username>\My Documents \ IISExpress\Config .

IISExpressConfigFiles thumb 5 Internal things that you should know about IIS Express

Open the “applicationhost.config” file in any text editor, and search for your web application name. You will find a section similar to the image shown in below.

ConfigurationSettings thumb 5 Internal things that you should know about IIS Express

As you can see this section contains the information related with the physical path of  IIS Express Virtual Directory, application pool  and the several bindings information.

The aplicationhost.config files are user specific.

#3 :  Applying Multiple Bindings With IIS Express

You can add additional bindings within the “bindings” elements to access your sites using different urls.

<bindings>
<binding protocol="http" bindingInformation="*:53294:localhost" />
<binding protocol="http" bindingInformation="*:53295:my-pc" />
<binding protocol="https" bindingInformation="*:44302:localhost" />
</bindings>

For an example if you have the above bindings in the binding configuration section, you will be able to acess the site using http://my-pc:53259 ( where my-pc has to be configure in your host files )

#4 : There is an additional application – IISExpressTray

When you press F5 to run the project, Visual Studio automatically launches the IIS Express and it will show up in your task-bar tray while it’s running.

 5 Internal things that you should know about IIS Express

You can right-click and  select the “Application”  to get the list of currently active URL’s for the current application.  To navigate, you have to click on the site URL.

IISApplicationHost thumb 5 Internal things that you should know about IIS Express

Along with the hosting sites, IIS Express ( IISExpress.exe)  is the parent process of an another application “IISExpressTray.Exe”. You can launch this application by just right click on IIS Express Icon on system tray icon and then select “Show All Applications” .

Following snaps shows the overall process hierarchy of IIS Express with in Visual Studio.

IISExpressTray thumb 5 Internal things that you should know about IIS Express

#5 : Quick way to get the details of the site configurations

From the application url lists, you can select any of the url / sites ; IISExpress tray application will show you different additional details such as runtime, application path and configuration file as shown the below image.

ApplicationDetails thumb 5 Internal things that you should know about IIS Express

This is the easiest option to open the application configuration file for IIS Express.

That’s all ! Hope going forward this information will help you to work with IIS Express.

Thanks