Konu, kullanıcı ve müdür arasındaki anlam ve fark nedir?
Yanıtlar:
Bunlar, cins, tür ve bireyin hiyerarşik olduğu gibi hiyerarşiktir.
- Konu - Güvenlik bağlamında, konu bir nesneye erişim isteyen herhangi bir varlıktır . Bunlar, erişim isteyen ve isteğin karşılandığı şeyi belirtmek için kullanılan genel terimlerdir. Bir uygulamada oturum açtığınızda konu sizsiniz ve uygulama nesnedir. Birisi kapınızı çaldığında, ziyaretçi erişim isteyen konudur ve eviniz nesneye erişim istenir.
- Asıl - Bir hesap, rol veya başka bir benzersiz tanımlayıcı ile temsil edilen öznenin bir alt kümesi . Uygulama düzeyi düzeyine geldiğimizde, ilkeler erişim denetim listelerinde kullandığımız benzersiz anahtarlardır. İnsan kullanıcıları, otomasyonu, uygulamaları, bağlantıları vb. Temsil edebilirler.
- Kullanıcı - Genellikle bir insan operatöre atıfta bulunan bir müdür alt kümesi . "Kullanıcı" veya "kullanıcı kimliği" kelimeleri genellikle "hesap" ile değiştirildiği için, ayrım zaman içinde bulanıklaşıyor. Ancak, temel olan şeylerin geniş sınıfı ile belirleyici olmayan bir şekilde işlemleri yürüten etkileşimli operatörler olan alt kümesi arasında ayrım yapmanız gerektiğinde , "kullanıcı" doğru kelimedir.
Konu / Nesne, gramerde kullanılan terimlerden miras kalır. Bir cümlede özne aktördür ve nesne üzerinde hareket edilen şeydir. Bu anlamda, bilgisayarlar icat edilmeden bu yana kullanım yaygın olmuştur. Güvenlik bağlamında, konu istekte bulunabilecek her şeydir. Yukarıda belirtildiği gibi, bunun BT güvenliği ile sınırlı olması gerekmemektedir ve bu nedenle çok geniş bir sınıflandırmadır. İlginç olan şey, öznenin nesneyi ima etmesidir. Nesne olmadan konu yoktur.
Prensipler, konuların çözdüğü şeydir. Kredi kartınızı sunduğunuzda konudur ve hesap numarası asıl kişidir. Diğer bağlamlarda, kullanıcı kimliğiniz veya devlet tarafından verilen kimliğiniz esastır. Ancak müdürler, insan olmayan birçok özne türüyle ilişkilendirilebilir. Uygulamalar sistem düzeyinde işlevler için istekte bulunduğunda, yönetici imzalı bir yürütülebilir kod modülünün imzacısı olabilir, ancak bu durumda bile isteği yönlendiren kullanıcı hala konudur.
Kullanıcı genellikle etkileşimli bir operatöre atıfta bulunduğundan, konudan veya prensipten daha spesifiktir. Bu yüzden bir Grafik Kullanıcı Arayüzümüz değil, bir Grafik Kullanıcı Arayüzümüz var. Kullanıcı, anapara çözümlenen konu örneğidir . Tek bir kullanıcı herhangi bir sayıda ilkeye karar verebilir, ancak herhangi bir yöneticinin tek bir kullanıcıya çözmesi beklenir (insanların kimlik paylaşmama gerekliliğine uyduğu varsayılarak). Yukarıdaki örnekte, bir çalıştırılabilir kod modülü imzalayan kesinlikle yok Kullanıcı, ama olan geçerli bir asıl. Modülü yüklemeye çalışan etkileşimli operatör kullanıcıdır.
Yorumlarda belirtildiği gibi, yetkili kaynaklar bile bu şartlar üzerinde anlaşmamaktadır. Bu yanıtı hazırlarken NIST, SANS, IEEE, MITER ve güvenlik sınav rehberleri gibi birçok "yarı yetkili" kaynak araştırdım. En azından yarı-yetkili olan bulduğum hiçbir kaynak üç terimi de kapsıyordu ve bunların kullanımında önemli farklılıklar vardı. Bu terimlerin nasıl kullanılması gerektiğini benimsemem, ancak pratik bir bakış açısıyla, gecenin ortasında bir el kitabını incelerken, tanımlar satıcı veya yazar ne derse desin. Umarım buradaki yanıtlar, sularda gezinmek ve bu şartları kullanarak herhangi bir güvenlik belgesini ayrıştırmak için yeterli bilgi sağlayacaktır.
John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
Kimlik Doğrulama konsept haritama bir göz atın :
Bence terminoloji JAAS'tan alınmıştır .
Bir uygulama kullanıcının (veya hizmet gibi başka bir varlığın) kimliğini doğrulamak için JAAS kimlik doğrulamasını kullandığında, sonuç olarak bir Konu oluşturulur. Konunun amacı kimliği doğrulanmış kullanıcıyı temsil etmektir. Bir Konu, her Müdürün o kullanıcı için bir kimliğini temsil ettiği bir dizi Müdürden oluşur . Örneğin, bir Konunun adı ("Susan Smith") ve Sosyal Güvenlik Numarası Müdürü ("987-65-4321") olabilir, böylece bu Konuyu diğer konulardan ayırt edebilir.
Konu , hizmet isteyen varlıktır. Bir kullanıcı veya bir işlem olabilir. Muhtemelen bu yüzden Kullanıcı yerine Konu adı seçildi.
Bir konu bir hizmete erişmeye çalıştığında, önce konunun kimliği doğrulanmalıdır. Başarılı kimlik doğrulaması , bu Konunun Güvenlik İlkelerinin yüklenmesi ile sona erer . Örneğin, Rol Tabanlı Erişim Kontrol sisteminde, kimliği doğrulanmış (oturum açmış) bir kullanıcının genellikle iki prensibi olacaktır - userId ve roleId. Bu tür sistemlerde, hem roller hem de kullanıcılar için ayrıcalıklar (yani neye erişebilecekleri) belirtilir. Yetkilendirme sırasında (örn. Talep edilen hizmete izin verilip verilmeyeceğini kontrol etmek), güvenlik sistemi her iki prensibe karşı erişilebilirliği kontrol edecektir.
Bu nedenle, yetkilendirme açısından, müdürler erişime izin verilen veya izin verilmeyen gerçek varlıklardır. Konu sadece bazı prensipleri tutan bir kullanıcı / evre / süreçtir.
T.Rob'un açıkladığı gibi, Konu bir nesneye erişim isteyen herhangi bir varlıktır. Bu noktadan başlayarak javax.security.auth.Subject koduna ÇOK yararlı ve anlaşılması kolay bulduğum bir yorum buldum:
"Özneler potansiyel olarak birden fazla kimliğe sahip olabilir. Her kimlik Özne içinde bir Asil olarak temsil edilir. Müdürler isimleri sadece bir Özneye bağlar. Örneğin, kişi olan bir Özne, Alice'in iki İlkesi olabilir: Alice Bar ", sürücü ehliyeti üzerindeki isim, Özne ve öğrenci kimlik kartındaki numarayı" 999-99-9999 "Özneye bağlayan bir diğeri. farklı bir ada sahip. "
Umarım yardımcı olur.
Bu, Oracle JAVA SE Documentation'ın aşağıdaki açıklaması için bir bağlantıdır .
Konular, İlkeler, Kimlik Doğrulama ve Kimlik Bilgileri Kaynaklara erişimi yetkilendirmek için, uygulamaların önce isteğin kaynağını doğrulaması gerekir. JAAS çerçevesi, talebin kaynağını temsil etmek için konu terimini tanımlar . Bir konu, kişi veya hizmet gibi herhangi bir varlık olabilir. Bir konu, javax.security.auth.Subject sınıfı tarafından temsil edilir .
Kimlik doğrulama , bir öznenin kimliğinin doğrulanma sürecini temsil eder ve güvenli bir şekilde gerçekleştirilmesi gerekir; aksi halde bir fail bir sisteme erişim elde etmek için başkalarını taklit edebilir. Kimlik doğrulama tipik olarak öznenin kimliğini kanıtlamak için bir tür kanıt göstermesini içerir. Bu tür kanıtlar yalnızca konunun büyük olasılıkla bileceği veya sahip olabileceği bilgiler (şifre veya parmak izi gibi) olabilir veya yalnızca konunun üretebileceği bilgiler olabilir (özel anahtar kullanarak imzalı veriler gibi).
Doğrulanmış sonra, bir Konusu ilişkili kimlikler veya doldurulur Müdürlerinin (tipi java.security.Principal ). Bir Konunun birçok İlkesi olabilir. Örneğin, bir kişi, diğer Konulardan ayıran bir Müdür ("John Doe") ve bir SSN Müdürüne ("123-45-6789") sahip olabilir.
İlgili İlkelere ek olarak, bir Öznenin kimlik bilgileri olarak adlandırılan güvenlikle ilgili öznitelikleri olabilir . Bir kimlik bilgisi, konuyu yeni hizmetlere doğrulamak için kullanılan bilgileri içerebilir. Bu kimlik bilgileri parolaları, Kerberos biletlerini ve ortak anahtar sertifikalarını içerir. Kimlik bilgileri, konunun belirli etkinlikleri gerçekleştirmesini sağlayan veriler de içerebilir. Örneğin, şifreleme anahtarları, konunun verileri imzalamasını veya şifrelemesini sağlayan kimlik bilgilerini temsil eder. Genel ve özel kimlik bilgisi sınıfları, temel J2SE API'sinin bir parçası değildir. Bu nedenle, herhangi bir sınıf bir kimlik bilgisini temsil edebilir.
rahulmohan'a göre bence, Kimlik Doğrulama alt jet olmadan önce, Kimlik Doğrulama pricipal olduktan sonra, fark olarak, bir alt jet birçok pricipal olabilir