Mehmet Giritli mehmet.giritli "at" kamu.ct.tr 18 Nisan 2020
Kullanıcı Yönetim Sistemi (KYS), Kamunet Güvenlik Sistemi (KGS)‘ni yönetmek için geliştirilmiş bir araçtır. Temel olarak, KGS’nin merkezi olarak çalışan OpenLDAP sunucusunda istenilen işlemleri gerçekleştirerek fonksiyonunu yerine getirir.
KYS’nin varlık amacı sadece Kamunet yöneticilerinin istediği işlemleri yerine getirerek onlara yardımcı olmak değil, aynı zamanda, KGS çerçevesinde çalışan yazılımların idamesinin farklı kurum bilişim sorumlularına delege edilmesini sağlayarak, bu sorumluların sadece kendi sorumluluk alanlarındaki yönetsel işlemleri kendilerinin gerçekleştirebilmelerini sağlar. Böylece, kullanıcı ve yazılım yönetim ihtiyaçlarından kaynaklı iş yükü “endpoint”lere dağıtılabilir.
KYS’nin bir diğer amacı ise, kamu kurumlarında kullanılmakta olan birbirinden farklı yazılımların, tek bir güvenlik sistemini kullanabilmelerini mümkün kılmasıdır. Böylece, kamu personelinin farklı yazılımları tek bir “güvenlik kimliğiyle” kullanmaları mümkün hale gelip, beraberinde güvenlikte yüksek ve yönetilebilir bir standardın oluşması sağlanabilir.
Bu metin boyunca, yönetim işlevini gerçekleştiren KYS kullanıcısını “yönetici” olarak, hesabı üzerinde işlem yapılan KYS kullanıcısını ise “kullanıcı” olarak adlandıracağız.
KYS, iki farklı tür yönetimi mümkün kılar. Bunlar “kullanıcı yönetimi” ve “yazılım yönetimi” olarak adlandırılır.
KGS kapsamında, LDAP sisteminin kullandığı hiyerarşik yapının seviyeleri genel olarak “alan” diye adlandırılır. KGS dokümantasyonunda da belirtildiği gibi, devlet kurumları hiyerarşisi LDAP yapısı içerisinde o (organization) tipi ve ou (organizationalUnit) tipi kayıtlarla oluşturulan hiyerarşik yapı ile temsil edilir. Bu bağlamda, her bakanlık bir o tipi kayıt ile ve bir bakanlığa bağlı her daire ise ou tipi kayıt ile temsil edilir. Herhangi bir bakanlığa bağlı bir kurum ise yine ilgili bakanlığa bağlı o tipi kayıt altında, başka bir o tipi kayıt ile temsil edilir. Hiyerarşiyi oluşturan tüm o veya ou tipi kayıtlar genel olarak “alan” olarak adlandırılır.
KYS, herhangi bir “alanda” yapılabilecek yönetim işlevini, herhangi bir yöneticiye yetki sistemini kullanarak delege edilmesini sağlayabilir.
Bir yöneticinin “kullanıcı yönetimi” menüsü altında işlem yapmasının asgari koşulları şöyledir:
Liste 1: Kullanıcı yönetimi – asgari koşullar.
Ancak yukarıda listelenen tüm koşullar yetine getirildiği takdirde bir yöneticiye bir alanın yönetimi delege edilebilir.
KYS’nin kullanıcı yönetimi bölümü, seçili olan alandaki kullanıcıların listelenmesi şeklinde tasarlanmıştır. Kullanıcının yetkili olduğu tüm alanlar, sol taraftaki filtre çubuğunda hiyerarşik yapıyı yansıtacak şekilde gösterilir. Filtre çubuğunda seçilmiş olan alan içerisinde yer alan tüm kullanıcılar, kullanıcı yönetimi ana ekranında gösterilir. Bu listeleme derin bir listeleme değildir: seçili alanın altında olan kullanıcılar listelenirken, seçili alanın alt alanları içerisinde yer alan kullanıcılar listelenmez.
Süper kullanıcılar listede farklı bir arka plan rengi kullanarak gösterilir.
Filtre çubuğunda, kullanıcının kendi hesabından oluşan özel sanal bir “alan”, farklı bir renkte gösterilir. Sadece kullanıcının kendi hesabından oluşan bu sanal alan, kullanıcıya her zaman görünür olacaktır. Kullanıcının yetkilendirildiği herhangi bir alan olmasa bile, bu özel sanal alan kullanıcıya her zaman filtre çubuğunda gösterilecektir.
Bu özellik, KYS’nin son-kullanıcılar için de kendi hesaplarını yönetebilecekleri bir arayüz olarak kullanılabilmesini sağlar.
Süper kullanıcılar için filtre çubuğundaki alan listesi, LDAP hiyerarşisinin tümünü içerecektir. Bu LDAP veritabanlarının tamamını kapsayacaktır.
Filtre çubuğunda seçili olan alan, ya da başka bir deyişle yönetilmekte olan alan, üst bölümde ana başlık olarak gösterilirken, alt başlık olarak bu alanın üst seviyesindeki o tipi alan da alt başlıkta gösterilir, böylece yönetilmekte olan alanın tam olarak hangi kuruma denk geldiği açıkça temsil edilmiş olur.
Yeni kullanıcılar ancak ou tipi alanlar içerisinde yaratılabilir. Pratikte bu, bakanlıklar altındaki dairelere karşılık gelmektedir. Diğer bir ifadeyle, bakanlıklar veya kurumlar gibi o tipi kayıtların içerisinde kullanıcı yaratılamaz.
Bu, OpenLDAP’tan kaynaklanan bir sorun pek tabii ki değildir. Sadece, Kamunet’in veritabanı hiyerarşisi düzenini sağlamaya yönelik bir politikasıdır. Yeni kullanıcıların yaratılabileceği alanlar filtre çubuğunda kalın harflerle gösterilir.
Bir yöneticinin, herhangi bir alan içerisine yeni kullanıcı ekleyebilmesi için, asgari olarak aşağıdaki koşulların yerine getirilmesi gerekir:
Daha fazla bilgi için “Kullanıcı Düzenleme” bölümüne göz atın.
Bir kullanıcının bilgilerinde değişiklik yapmak için, kullanıcının bulunduğu alanın filtre çubuğunda seçili halde olması gerekir. Bu, hesabı düzenlenecek kullanıcının gösterilmekte olan listede yer almasını sağlar.
Bir yöneticinin, bir alan içerisindeki bir kullanıcının bilgilerini düzenleyebilmesi için asgari olarak aşağıdaki koşulların sağlanması gerekir:
Her kullanıcı için mevcut olan “düzenle” düğmesi kullanıcı bilgilerini düzenlenebilecek şekilde ekrana getirecektir. Zorunlu alanlar kırmızı * işareti ile gösterilir. “Görünür isim” alanı, otomatik olarak unvan, adı ve soyadı alanlarını kullanarak oluşturularak kolaylık sağlanır. Bu alan pek tabii ki manüel olarak da değiştirilebilir. Bu işlem, adı, soyadı ve unvan alanları belirlendikten sonra yapılmalıdır. Benzer şekilde “kullanıcı adı” alanı da otomatik olarak adı ve soyadı alanlarından üretilir. Bu alan da öncekine benzer şekilde manüel olarak pek tabii ki ayarlanabilir.
Kullanıcı hesabının “aktif” olmadığı durumlarda, kullanıcı KGS kapsamında çalışan herhangi bir yazılımı kullanamaz ve bu bilgi kendisine giriş yapmaya çalıştığı anda, hesabının pasif durumda olduğu yönündeki mesaj ile bildirilir.
Süper kullanıcı seçimi, ancak işlemi gerçekleştiren yönetici bir süper kullanıcı ise gösterilir. Aksi halde bu bölüm işlemi gerçekleştiren yöneticiye görünür olmaz. Bu, aynı zamanda şu anlama da gelmektedir: Bir süper kullanıcının süper kullanıcı yetkisini ancak bir diğer süper kullanıcı geri alabilir. Ayrıca, bir kullanıcıyı süper kullanıcıya ancak bir diğer süper kullanıcı dönüştürebilir. Süper kullanıcılar, KGS kapsamında sınırsız yetkilere sahip olduklarından çok sınırlı sayıda kullanıcıya verilmesi gereken bir roldür.
Şifre bilgisi, düzenleme durumunda zorunlu değildir. Eğer bu alan düzenleme sırasında boş bırakılırsa, bu güncellemenin şifre değişimini kapsamayacağı anlamına gelir.
Dilenen miktarda e-posta adresi ve cep telefonu numarası bir kullanıcıya verilebilir. Cep telefonu numarası zorunlu olmamakla birlikte, KGS’nin yeni şifre hatırlatma/yeni oluşturma özelliği cep telefonu kayıtlı olmayan kullanıcılar tarafından kullanılamaz.
Son olarak, “belge türü” listesi, seçili ülke için dinamik olarak yüklenir ve sadece seçili ülke için kabul gören ve kimlik yerine geçen belge türlerini gösterir.
Ekleme ve düzenleme işlemleri ile birlikte kullanılan modüller için Kullanıcı Ekleme Modülleri bölümüne göz atın.
Bir yönetici, yetkili olduğu alan içerisindeki kullanıcıların hesaplarına, kullanımları için, yetkili olduğu yazılımları ekleyip çıkarabilir. Bunun için ilgili sütun altında sunulan yazılım listesinden seçim yapıp, ekle/çıkar düğmesine tıklanması yeterlidir.
Yöneticinin yetkili olmadığı yazılımlar yazılım listesinde görünmeyecektir. Diğer taraftan, süper kullanıcılar KYS’ne kayıtlı tüm yazılımları ekleyip çıkarabilirler.
Bir yöneticinin, bir kullanıcı hesabına yazılım ekleyip çıkarabilmesi için asgari koşullar şöyledir:
Kullanıcılara yeni yazılım eklendiği zaman, kullanıcı hesabının yazılım için olan durumu pasif hale getirilir. Ayrıca, herhangi bir geçerliliği olmayan “dummy” bir yetki de bu yazılım için otomatik olarak verilir. Dolayısıyla, bir kullanıcıya yazılım eklemesi yapıldıktan sonra, “Yetki Yönetimi” bölümünden gerekli ayarların yapılması gerekir.
Kullanıcılardan yazılım çıkarıldığı zaman, yazılımla ilgili tüm veriler silinir. Buna, kullanıcının tüm yetkileri, hesap durumu, son giriş zamanı ve IP bilgisi ve hatalı girişleri tutan sayaçları da dahildir.
Bir yönetici, yetkili olduğu alandaki kullanıcıları silebilir. Bu işlemin geri dönüşü yoktur ve kullanıcıya ait tüm bilgiler, kullanıcının kullanımında olan tüm yazılımlarla ilgili tüm bilgiler dahil olmak üzere silinir.
Bir kullanıcının, herhangi bir alan içerisindeki bir kullanıcıyı silebilmesi için, asgari olarak şu koşulların yerine getirilmesi gerekir:
Filtre çubuğu kullanarak seçili olan alan içerisinde, verilen bir anahtar ile arama gerçekleştirilebilir. Verilen anahtar “adı”, “soyadı”, “e-posta”, “notlar” ve “belge numarası” özellikleri içerisinde aranarak bulunan kullanıcılar listelenecektir.
Kullanıcı yönetimi bölümünden farklı olarak, yetki yönetimi bölümünde gösterilen kullanıcılar bir alana ait olanlar değil ama filtre çubuğunda seçili olan yazılımı kullanma yetkisine sahip olan tüm kullanıcılardır.
Filtre çubuğunda listelenen yazılımlar, yöneticinin yetkilendirildiği yazılımlardan oluşur. Süper kullanıcılar içinse, KYS’ne kayıtlı tüm yazılımlar listelenir.
Süper kullanıcılar, kullanıcı yönetiminde olduğu gibi listede farklı bir arka plan rengi kullanarak gösterilir.
Listelemede kullanılan bilgiler “kullanıcı yönetimi” bölümündeki bilgilerle genelde ortak olmasına rağmen, kullanıcının söz konusu yazılımla ilintili bilgilerini de ek olarak içerir.
“Yazılım durumu” kullanıcının söz konusu yazılımı kullanmaya hesabının açık olup olmadığını belirtir. Yazılım durumu “kullanıcı yönetimi” bölümünden değiştirilebilir. Diğer taraftan, “genel durum” kullanıcının hesabının herhangi bir yazılımı kullanmaya açık olup olmadığını belirtir. Genel durum, “yetki yönetimi” bölümünden değiştirilebilir.
“Son giriş” ve “son giriş IP” sırasıyla kullanıcının yazılıma giriş yaptığı en son tarihle zamanı ve IP adresini gösterirler. “Son hatalı giriş” bilgisi kullanıcının giriş sırasında sağladığı hatalı şifre veya herhangi bir sistem hatasının oluştuğu en son tarihle zamanı verir. Son olarak, “Hatalı girişler” bilgisi iki sayacın değerlerini verir: Bunlardan ilki, kullanıcının son başarılı girişinden sonra gerçekleşen başarısız girişlerin toplam sayısı, ikincisi ise kullanıcının tüm başarısız girişlerinin sayısıdır. Söz konusu yazılım kullanıcı hesabından kaldırıldığında, bu paragrafta tarif edilen tüm bilgiler kaybolur ve geri getirilemez.
Bir yöneticinin “Yetki yönetimi” bölümünü kullanabilmesi için gerekli asgari koşullar şöyledir:
Liste 2: Yetki yönetimi – asgari koşullar.
Yönetici, listelenen her kullanıcı için söz konusu yazılımdaki yetkilerini “Yetki Yönetimi” düğmesine tıklayarak değiştirebilir.
Yetki yönetimi erkanı temel olarak iki pencereden oluşur. Sol pencere kullanıcının sahip olduğu yetkileri gösterirken, sağ pencere yazılıma ait ve kullanıcının henüz sahip olmadığı yetkileri gösterir.
Yetkiler sürükle-bırak şeklinde pencereler arası taşınabilen dörtgenler şeklinde temsil edilirler. Bir yazılıma ait yetkilerin ne olduğu, “yazılım kayıt” bölümünde belirlenir. Verilen yetkiler yeşil, verilmeyen yetkiler kırmızı renk tonlarındaki dörtgenler ile gösterilirler. Gerekli değişiklikler yapıldıktan sonra “Değişiklikleri Kaydet” düğmesine tıklayarak kaydedilmeleri gerekir.
Eğer KYS’ne kayıtlı bir yazılımın yetkileri arasında bulunmayan herhangi bir yetki OpenLDAP veri tabanından okunmuşsa, bu “tanımsız yetki” olarak adlandırılır ve siyah renk bir dörtgen ile gösterilir. Tanımsız yetkilere sahip bir düzenleme kaydı yapılamaz. Böyle bir durumda, tanımsız yetkinin “yazılım kayıt” bölümünden kayıt altına alınması veya silinmesi gerekir. Tanımsız yetkiyi silmek için, yetki dörtgenini “kullanıcının sahip olmadığı yetkiler” penceresine taşıyıp değişikliklerin kaydedilmesi yeterlidir. Bu durumda tanımsız yetki KYS kayıtlarından tamamen çıkarılır.
Diğer taraftan * sembolü ile sonlanan “wildcard” yetkilerin her birisi birden fazla yetkiye “denk” olabilir (wildcard yetkiler için KGS belgelerine göz gezdirin). Bu tür yetkiler, “wildcard yetki” tarafından “ima edilen yetkiler” olarak adlandırılırlar. Fare imlecinin bir “wildcard yetki” üzerinde gezdirilmesi durumunda, bu yetkinin “ima edilen yetkileri” parlak yeşil renk tonunda o an için gösterilir ve “wildcard yetkinin” hangi yetkilere denk olduğu kolayca görülebilir.
Son olarak dinamik olarak üretilebilen yetkiler sarı kesik çizgilerle çevrelenmiş olarak gösterilir. Dinamik yetkiler için “Yazılım Kayıt” bölümünde ilgili başlık altına göz gezdirin.
Bir yöneticinin, bir kullanıcının yetkilerinde değişiklik gerçekleştirebilmesi için gerekli asgari koşullar şöyledir:
Bir yönetici, bir kullanıcının kullanımında olan bir yazılımın durumunu aktif veya pasif duruma alabilir. Pasif durumunda alındığında, kullanıcı hesabı o yazılıma giriş sağlayamaz. Bu, kullanıcı hesabının diğer yazılımlardaki durumunu etkilemez. Bir kullanıcıya yeni bir yazılım eklendiği zamanlarda, hesap bu yazılım için başlangıçta pasif duruma getirilir.
Hesap durumu, “Yetki Yönetimi” bölümünden değiştirilebilir. Bunun için söz konusu yazılımı filtre çubuğundan seçerek, yazılımın kullanıcıları arasından ilgili kullanıcının yetki yönetimine giriş sağlanır. Burada “Hesap bu yazılım için aktif durumda” işareti ayarlanarak hesap istenilen duruma geçirilebilir.
Bir yöneticinin yazılım durumunu değiştirebilmesi için asgari koşullar, “Yetki Yönetimi” bölümünde listelenen koşullar ile aynıdır.
Filtre çubuğu kullanarak seçili olan yazılım kullanıcıları içerisinde verilen bir anahtar ile arama gerçekleştirilebilir. Verilen anahtar “adı”, “soyadı”, “e-posta”, “notlar” ve “belge numarası” alanları içerisinde aranarak bulunan kullanıcılar listelenecektir.
KYS’nin yetkilendirme modeli, yöneticilerin belirli alanlar ve yazılımlar için yetkilendirilmiş olmaları kavramını temel alır. Bir yöneticinin bir alan için yetkilendirilmiş olması, KYS yazılımının bazı yetkilerinin o yöneticiye verilmesiyle sağlanır: Bir yöneticiyi bir alan için yetkilendirmek için:
Dikkat: Bir alan için yapılan yetkilendirme, o alanın alt alanlarını kapsamaz.
Bir yöneticinin alan yetkilendirmesi yapabilmesi için asgari koşullar, “Yetki Yönetimi” bölümünde listelenen koşullar ile aynıdır.
Bir yöneticiyi bir yazılım için yetkilendirmek, bir alan için yetkilendirme işlemine çok benzer. Gerekli adımlar şöyledir:
Bir yöneticinin alan yetkilendirmesi yapabilmesi için asgari koşullar, “Yetki Yönetimi” bölümünde listelenen koşullar ile aynıdır.
KYS, KGS bünyesindeki yazılımlarla ilgili işlemleri gerçekleştirebilmesi için, ilgili yazılımların kaydedilmiş olmasını zorunlu kılar. Kaydedilmemiş yazılımlar her ne kadar giriş işlemlerini sorunsuz bir şekilde yürütebiliyor olsalar da, bu yazılımlarla ilgili yönetim işlemleri KYS üzerinden gerçekleştirilemez.
Yeni bir yazılım kaydı eklemek veya değiştirmek için “Yazılım Kayıt” bölümü kullanılır. Bu bölümü kullanma yetkilerinin sadece süper kullanıcılara verilmesi tavsiye edilir. Bu bölümdeki yazılım kayıtlarının değiştirilmesi için, ilgili yazılım yetkisi aranmaz. Sadece, KYS’nin “Yazılım Kayıt” bölümü yetkileri ile bir sınırlandırma yapılmaktadır. Başka bir deyişle, KYS’nin “Yazılım kayıt listeleme”, “Yazılım kayıt oluşturma ve kaydetme”, “Yazılım kayıt bilgilerini görme ve güncelleme”, “Yazılım kayıt silme” yetkilerinin herhangi bir alt kümesine sahip olan bir yönetici, bu yetkilerden sahip oldukları çerçevesinde, tüm yazılım kayıtları üzerinde ilgili işlemleri gerçekleştirebilir.
Yeni yazılım kaydı, yazılım adı dışında (bu alan tekildir, i.e., aynı isimde birden fazla yazılım kaydı yapılamaz), iki temel unsur içerir. Bunlardan ilki yazılıma atanmış olan OID değeridir. OID ile ilgili bilgiler KGS belgelerinde kapsamlı olarak verilmektedir. OID değeri, Kamunet kök OID’i ile başlamalıdır.
Çoğu durumda, yeni kayıtlar için OID giriş alanında hazır halde sunulan kök OID’i sonuna tek bir rakam eklemek yeterli olacaktır.
Eğer yazılımın birden fazla kurulumu olacaksa, kök OID değerine ana yazılımı temsilen eklenen ilk rakamın ardına, ek bir “.” ayracı kullanarak ve ardına da, her bir kurulum için 1’den başlayacak şekilde ek bir rakam eklenerek farklı OID değerleri kullanılmalıdır. Dolayısıyla, böyle bir durumda her kurulum için ayrı bir yazılım kaydı oluşturmak gerekir.
Yazılım kayıtlarının ikinci temel unsuru ise yetki tanımlarıdır. Bir yazılıma ait tüm yetkiler KYS tarafından bir metin parçasına dönüştürülerek yöneticiye sunulur ve yine aynı biçimi kullanarak yöneticiden girişleri kabul edilir. Bu metnin her satırı farklı bir yetkiye denk gelir.
Her yetki satırı, virgüllerle ayrılmış en az iki, en fazla üç bölümden oluşabilir. İlk iki bölüm, sırasıyla “yetki kodunu” ve yetkinin görünür adını içermelidir. Bu iki bölüm zorunlu olanlardır. Üçüncü bölüm, yetkilerle ilgili notlar için kullanılır ve zorunlu değildir. Dolayısıyla, her yetki satırı bir veya iki virgül “,” sembolü içerebilir.
Yetki kodları, söz konusu yazılım için tekil olmak zorundadır. Yetki kodları yazılım kök OID’ini içermezler. Her ne kadar LDAP kaydında her yetki yazılım kök OID’ine eklenen yetki kodu ile oluşturulsa da, KYS arayüzünde sadelik amacıyla kök OID yetki tanımları için kullanılmaz. LDAP içerisinde tutulan ve kök OID’ini de içeren yetki tanımı “tam yetki kodu” olarak adlandırılır. Tam yetki kodları, “Yetki Yönetimi” bölümünde dörtgenler olarak temsil edilen yetkilerin üzerinde fare imleci gezdirilerek görülebilir.
Dinamik yetkiler dışında, yetki kodları sadece rakam ve “.” ayraçlarından oluşabilir. Diğer taraftan, dinamik yetki kodları için bu durum biraz daha farklıdır.
Bazı durumlarda statik bir şekilde belirlenmiş yetkiler, yazılımların güvenlik ihtiyaçlarını karşılamada yetersiz olabilir. Eğer bir yazılım sürekli değişkenlik gösteren bir kavram etrafında yetki verme gereksinimine sahipse, dinamik yetkiler bu ihtiyaçları karşılayabilir.
Örneğin, KYS’nin kendisi de alan ve yazılım yetkileri için dinamik yetkiler kullanır: KYS’ne kaydedilmiş her yazılım için KYS’nin ayrı bir yetki kullanması gerekir. KYS’ndeki yazılımlar statik olmayıp, sürekli değişiklik göstereceğinden, her yazılıma karşılık gelen bir yetki üretmek için statik yetkiler yetersiz kalacaktır (ancak her yeni yazılım için manüel olarak yeni bir yetki yaratmak dışında, ki bu da pek pratik bir çözüm olmayacaktır). KYS’nin kullandığı ilgili dinamik yetki, “yetki yönetimi” bölümü yüklendiği anda, tüm yazılım kayıtlarını okuyup, bunların her birisi için ayrı bir yetki üretir ve bunları “yetki yönetimi” bölümünde gösterir. Bundan sonrası statik yetkilerde olduğu gibi çalışır: “Üretilen” yetkilerin her birisi bir kullanıcıya verilebilir veya verilmeyebilir.
Dinamik yetkiler “yazılım kayıt” bölümünde verilirken statik yetkiler ile benzer kurallar kullanılır. Aradaki tek fark, yetki kodunun sonuna “#” ayracı kullanılarak dinamik yetki adı ve parametrelerinin verilmesidir. Parametreler, dinamik yetki adından ve birbirlerinden “.” ayracı kullanarak ayrılırlar. Bu bilgiler dinamik yetkiyi çalıştıran fonksiyonu çağırmak için kullanılır. Genel dinamik yetki şablonu aşağıdaki gibidir:
Dinamik yetki şablonu
<yetki kodu>#<dinamik yetki adı>.<p1>.<p2>...<pn>
Her dinamik yetki, PHP dilinde ile yazılmış basit bir eklenti kullanarak oluşturulur. Bu eklenti, sunucuda KYS kök klasörü altında, özel bir klasöre yerleştirilir:
Dinamik yetki eklentileri dosya yolu, KYS kök klasörüne göreceli.
app/DinamikYetkiler
Eklentinin, sonu “.php” ile biten ve dinamik yetkinin adına sahip bir dosya olması gerekir. Bu isim, yetki kodunda “#” işareti sonrası gelen kısımdır. Eklenti dosyasının yine dinamik yetki adı ile aynı ada sahip bir sınıfı olmalı ve bu sınıfın public tipinde “yukle” isimli bir method’u içermesi gerekir. Bu method, dinamik yetki tanımında kullanılan parametre sayısı kadar parametre kabul etmelidir.
“yukle” fonksiyonu değer olarak bir diziler dizisi döndürmelidir. İkinci boyuttaki her dizi, ayrı bir yetki oluşturacaktır. İkinci boyuttaki her dizi üç özel anahtar içermelidir. Genel olarak döndürülen dizi yapısı şöyle olmalıdır:
[
[
"oid_suffix" => <yetki kodu>,
"adi" => <yetki adı>,
"notlar" => <yetki notları>
]
...
]
Dinamik yetki çalıştırıldığı zaman, geri döndürülen diziler dizisinin her üyesinin “oid_suffix” anahtarının değeri, yetkiyi oluşturan ana unsurdur. Bu değer, dinamik yetki tanımının “#” ayracına kadar (ayracı içermeden) olan bölümün sonuna “.” ayracı eklendikten sonra yapıştırılır. Böylece yetki kodu oluşturulmuş olur.
Dinamik yetkilerin çalıştırılması sırasında oluşacak hatalar KYS’nin “İşlem Kayıt” bölümünden takip edilebilir.
Örnek olarak aşağıdaki dinamik yetki kodunu ele alalım:
1.1#ornek.2.3,Dinamik Yetki,İlk yetki notları
Karşılık gelen dinamik yetki eklentisinin dosya yolu aşağıdaki gibi olmalıdır:
<KYS dosya yolu>/app/DinamikYetkiler/ornek.php
Verilen tanıma karşılık gelebilecek örnek bir kaynak kodu aşağıda verilmektedir. Bu kod ile dinamik yetki iki farklı yetki üretecektir:
<?php
namespace App\DinamikYetkiler;
class ornek {
public function yukle ( $p1 , $p2){
return [ ["oid_suffix" => $p1 + $p2,
"adi" => "Toplamlar",
"notlar" => "Birinci yetki" ],
["oid_suffix" => $p1 * $p2,
"adi" => "Çarpımlar",
"notlar" => "İkinci yetki" ] ];
}
}
Bu eklenti ile dinamik olarak üretilecek iki yetki statik olarak yazılmış olsalardı, aşağıdaki yetki tanımlarına eşit olurlardı:
1.1.5,Toplamlar,Birinci yetki
1.1.6,Çarpımlar,İkinci yetki
“Yetki yönetimi” bölümünde dinamik olarak üretilmiş yetkiler sarı ve kesik çizgilerle çevrelenmiş dörtgenler olarak gösterilirler. Her dörtgen için, tanımlarında kullanılmış isimler üst başlık olarak gösterilirken, eklenti tarafından “adi” anahtarı ile döndürülmüş olan isimler alt başlık olarak gösterilecektir.
Yeni bir kullanıcı ekleme işlemi gerçekleştirilirken veya var olan bir kullanıcı hesabı düzenlenirken, bazı rutin işlemlerin yapılmasını kolaylaştırmak için KYS, “modül “olarak adlandırılan eklentilerle genişletilir bir sistem kullanır.
Modüller, her kullanıcı hesabı işlemi öncesi veya sonrasında belirli işlemleri gerçekleştirmek için kullanılırlar. Örneğin, bir kullanıcı hesabı ekleme veya değiştirilme işlemi gerçekleştirildiğinde, kullanıcıya işlemle ilgili bir e-posta bildirimi göndermek için kullanılabilirler. Bir diğer modül, kullanıcı şifresinin karmaşıklık derecesini kontrol edip, söz konusu işlemi yeterli şifre karmaşıklığı bulunmadığı zamanlarda engellemesi için kullanılabilir.
KYS, iki modül tipi tanımlar. “Ön modüller” diye adlandırılan modüller, kullanıcı ekleme/değiştirme işlemi henüz gerçekleşmeden çalıştırılan modül tipidir. “Arka modül” diye adlandırılan modüllerse, ekleme/değiştirme işlemi gerçekleştirildikten sonra çalıştırılan modül tipleridir. Herhangi bir modül, gerçekleştireceği işleme göre “ön modül” veya “arka modül” olarak tanımlanabilir.
Modüller KYS veri tabanında “kullaniciEklemeModulleri” tablosundaki kayıtlar kullanılarak yüklenir. Bu tabloda her satır bir modüle denk gelir. Her satırın “sinif” değeri o modülün tanımlayıcı anahtarı olur. Bu alan tekildir.
Modüller, kodda herhangi bir değişim gerektirmeden bir eklenti sistemi ile çalıştırılırlar. Bu sistem, dinamik yetkilerde kullanılan sistem ile çok benzerdir. Modüller, PHP ile yazılmış basit bir eklenti kullanarak oluşturulur. Modül eklentileri, sunucuda KYS kök klasörü altında, özel bir klasöre yerleştirilirler:
Modül eklentileri dosya yolu, KYS kök klasörüne göreceli.
app/DinamikModuller
Eklentinin dosya adının modülün “kullaniciEklemeModulleri” tablosındaki “sınıf” değerinin sonuna “.php” eklenmesinden oluşması gerekir. Eklenti dosyasının yine “sinif” değeri ile aynı isimde bir sınıfı olmalı ve bu sınıfın public tipinde “yukle” isimli bir method içermesi gerekir.
“yukle” methodu tek bir parametre kabul etmelidir. Bu parametre ile eklenti koduna modülün, “kullaniciEklemeModulleri” tablosundki modeli gönderilir. Böylece modül hakkında bilgiler modül tarafından erişilebilir.
Modüllerin çalıştırılma sırasında oluşacak hatalar KYS’nin “İşlem Kayıt” bölümünden takip edilebilir.
“yukle” methodunun “hata” ve “mesaj” anahtarlarını içeren tek boyutlu bir dizi döndürmesi gerekir. Geri dönüş şablonu aşağıda gösterildiği şekilde olmalıdır:
[
"hata" => <true>|<false>,
"mesaj" => <Geri döndürülecek mesaj>,
]
Modüllerin “kullaniciEklemeModulleri” tablosunda mevcut bir diğer özelliği de “hatadaDur” sütunu ile kontrol edilebilen akış kontrolüdür. “hatadaDur” değeri “true” olan bir modülün, geri döndürdüğü dizide “hata” anahtarının değerinin “true” olması durumunda, akışın durdurularak “mesaj” anahtarı ile döndürülen değerin hata mesajı olarak (servis veya arayüz ile) gösterilmesini sağlar. Eğer söz konusu modül bir ön modül ise, hiçbir kullanıcı hesabı üzerinde hiçbir işlem gerçekleştirilmez. Eğer modül bir arka modül ise, talep edilen hesap işlemi gerçekleştirilir, fakat akış durdurulduğundan, geriye kalan modüller, eğer varsa, çalıştırılmaz.
“hatadaDur” değeri “false” olan bir modül, “hata” anahtarı “true” olan bir geri dönüş gerçekleştirirse, akış bu modül tarafından engellenmez fakat, “mesaj” anahtarı ile döndürülen mesaj (servis veya arayüz ile) gösterilir.
Aşağıdaki tablo, “kullaniciEklemeModulleri” veri tabanı tablosunda ayarlanabilen özelliklerin bir listesini verir. Modüller ancak bu tabloda yapılacak ekleme veya değişikliklerle kontrol edilebilirler.
| Özellik | Açıklama |
| tur (enum) | “onModul”/”arkaModul” değerlerinden birisi. |
| herZamanKullan ( boolean) | TRUE olması durumunda, modül istekle talep edilmese bile, her durumda çalıştırılacağını gösterir. Bu hem servisler hem de KYS arayüzü için geçerlidir. |
| hatadaDur (boolean) | TRUE olması durumunda, eğer modül hata döndürürse, işlem akışı durdurulup, modülün döndürdüğü mesaj geri döndürülür. Eğer söz konusu modül bir ön modül ise, hesap üzerinde herhangi bir işlem gerçekleştirilmez. |
| sira (int) | Modüllerin çalışma sırasını belirler. Küçük “sira” değerine sahip modül, büyük değere sahip modüllerden önce çalıştırılır. Eşit “sira” değerine sahip modüllerin çalıştırılma sırası tanımsızdır. |
| yeniKullaniciyaUygula (boolean) | TRUE olması durumunda, işlem yapılacak kullanıcı hesabı ancak yeni yaratılmakta olan bir hesap ise modülün kullanılacağını gösterir. |
| degisenKullaniciyaUygula (boolean) | TRUE olması durumunda, işlem yapılacak kullanıcı hesabı ancak önceden var olan ve değiştirilecek bir hesap ise modülün kullanılacağını gösterir. |
Kullanıcı şifresinin kullanıcının ismini içerip içermediğini kontrol eden “SifreZorlugu” adında basit bir modül kodu ile bu bölümü bitirelim:
<?php
namespace App\DinamikModuller;
class SifreZorlugu {
public function yukle ( $modulDBbilgisi ){
$sifre = request()->userPassword;
$adi =request()->givenName;
if ( strpos($sifre, $adi) === TRUE )
return ["hata" => true,
"mesaj" => "Şifreniz isminizi içeremez!"];
else
return ["hata" => false, "mesaj => ""];
}
}
| Sınıf | Hatada Durdurur | Ön/Arka | Her Zaman | Yeni | Düzenleme | Açıklama |
| sifreKontrol* | Ö | X | X | Şifre karmaşıklığını kontrol et. | ||
| sifreKontrolStrict* | X | Ö | X | X | Şifre karmaşıklığını kontrol et. | |
| epostaYeniBilgilendir | A | X | Hesap oluşturulduğunda kullanıcının e-posta adreslerine bilgilendirme gönder. | |||
| epostaDuzenBilgilendir | A | X | Hesap değiştirildiğinde kullanıcının e-posta adreslerine bilgilendirme gönder. | |||
| smsYeniBilgilendir | A | X | Hesap oluşturulduğunda kullanıcının cep telefonuna bilgilendirme gönder. | |||
| smsDuzenBilgilendir | A | X | Hesap değiştirildiğinde kullanıcının cep telefonuna bilgilendirme gönder. | |||
| nufusKontrol | Ö | X | X | Nüfus Kayıt’tan KKTC kimlik numarası, ad ve soyad kontrolü gerçekleştir. | ||
| nufusKontrolStrict | X | Ö | X | X | Nüfus Kayıt’tan KKTC kimlik numarası, ad ve soyad kontrolü gerçekleştir. | |
| telefonKontrol | Ö | X | X | BTHK’ndan cep telefonu numarası, ad ve soyad kontrolü gerçekleştir. | ||
| telefonKontrolStrict | X | Ö | X | X | BTHK’ndan cep telefonu numarası, ad ve soyad kontrolü gerçekleştir. |
* Şifre kalite kontrolü cracklib ve libpwquality kütüphanelerini kullanarak gerçekleştirilmektedir.
KYS, RESTful standardını kullanarak gövdesi JSON biçimindeki verilerden (“payload”) oluşan HTTP istek ve cevaplarını kullanan servisler sunar.
Güvenlik açısından KYS, OAuth2 standardı kapsamında güvenlik yöntemi kullanarak sağlanan servislerin tüketilmesini mümkün kılar. Servis, “Client Credentials” tipi “grant” kullanarak çalışmaktadır. Bu, söz konusu servisleri tüketecek olan istemcilerin (clients) KYS’ye önceden kayıt ettirilmiş olup, OAuth2 jargonu ile, “client secret” ve “client id” bilgilerine sahip olmasını gerektirir. Bu değerleri öğrenmek ve kayıt işlemi için Kamunet’e başvurmanız gerekir.
Aşağıda verilmiş örnek PHP/Laravel kaynak kodu yeni kullanıcı ekleme servisinin nasıl tüketileceğini gösterir. Örnek için Guzzle HTTP paketi kullanıllmıştır. Bu paket composer kullanarak kolayca kurulum işlemi yapılabilir:
composer require guzzlehttp/guzzle
Temel servis bilgileri şöyledir:
endpoint: <KYS sunucusu>/api/yeniKullaniciYarat method: PUT payload: JSON
Servis çağrılırken kullanılabilir alanlar aşağıdaki gibidir. Alanlar için kabul edilebilir değerler için KGS belgelerine göz gezdirin. “belgeTuru” vb. diğer alanlar için ön tanımlı değerlerden birisinin seçilmesi zorunludur. KGS belgeleri bu konulara açıklık getirir.
| Anahtar | Zorunlu? | Açıklama |
| entryuuid | X | Yeni kullanıcının LDAP hiyerarşisi içerisinde yaratılacağı noktaya ait UUID. |
| namingContext | X | “entryuuid” değerinin yer aldığı LDAP naming context.* |
| givenName | X | Adı. |
| sn | X | Soyadı. |
| cn | X | Görünür adı. |
| uid | X | Kullanıcı adı. |
| X | E-posta dizisi. | |
| userPassword | (yeni kayıt için) | Şifre. Var olan hesaplar için eksikliği eski şifrenin korunacağı anlamına gelir. |
| mobile | Cep telefonu dizisi. | |
| belgeTuru | Kullanıcının kimlik yerine geçen belge türü.* | |
| belgeNo | “belgeTuru” ile belirtilmiş belgedeki numara. | |
| ulke | Uyruk.* | |
| cinsiyet | Cinsiyet.* | |
| notlar | Kullanıcı hesabına eklenecek ek notlar. | |
| initials | Unvanlar. | |
| KAMUNETaktifHesap | Genel hesap durumu. “TRUE” durumunda hesap aktifleştirilir, “FALSE” durumunda pasifleştirilir.* | |
| moduller | Kullanılacak modül sınıflarından oluşan dizi.** |
* Bu anahtarlar için geçerli ve kabul edilebilir değerler KGS belgelerinde belirtilmiştir.
** Bu dizide yer alabilecek değerler için Mevcut Modüller bölümüne bakın. Bir modül için bu diziye katılması gereken değer o modülün “sınıf” değeridir.
<?php
namespace App\Http\Controllers;
use GuzzleHttp\Client;
use GuzzleHttp\Exception\RequestException;
class servisTest extends Controller{
public function yeniKullaniciYarat () {
//KYS sunucusu
$kys = "";
$istemciAnahtari = "";
$istemciId = "";
// OAuth2 yetkilendirme.
$guzzleNesne = new \GuzzleHttp\Client;
try {
$cevap = $guzzleNesne->post( $kys . '/oauth/token',
['verify' => false,
'headers' => [ 'Accept' => 'application/json'],
'form_params' => [ 'grant_type' => 'client_credentials',
'client_id' => $istemciId,
'client_secret' => $istemciAnahtari,
'scope' => 'kullaniciEkleme' ] ] );
}
catch (RequestException $e) {
if ($e->hasResponse()) {
// Servise bağlanıldı ama HTTP hatası oluştu
// HTTP kodu: $e->getCode()
// Hata mesajı: $e->getMessage()
//Hata içeriği: json_decode( $e->getResponse()->getBody()->getContents() , true ) );
}
else {
// Servise bağlanılamadı, bağlantı hatası?
// Hata mesajı: $e->getMessage()
}
}
$accessToken = json_decode((string) $cevap->getBody(), true)['access_token'];
// servis
$guzzleNesne = new \GuzzleHttp\Client(['base_uri' => $kys]);
$yeniKullaniciBilgisi = [
//ZORUNLU ALANLAR
"entryuuid" => "32c3cd57-44a4-4c17-b373-81b524cee32c", //yabancı şahıslar
"namingContext" => "dc=com,dc=ct,dc=tr",
"givenName" => "Adı",
"sn" => "Soyadı",
"cn" => "Adı Soyadı",
"uid" => "adı.soyadı",
"mail" => ["eposta1@gmail.com","eposta2@gmail.com"],
"userPassword" => "123456",
// OPSİYONEL
"mobile" => ["5338999999"],
"belgeTuru" => "kimlik6",
"belgeNo" => "123456",
"ulke" => "CT",
"cinsiyet" => "erkek",
"notlar" => "Kullanıcı hakkında bazı notlar",
"initials" => "Dr.",
"KAMUNETaktifHesap" => "FALSE",
"moduller" => ["sifreZorlugu" , "otomatikCN"],
];
//servisi çağır
try {
$sonuc = $guzzleNesne->request( 'PUT',
"/api/yeniKullaniciYarat",
[ 'verify' => false,
'headers' => [ 'Accept' => 'application/json',
'Content-Type' => 'application/json',
"Charset" => 'UTF-8',
'Authorization' => 'Bearer '.$accessToken, ],
'body' => json_encode($yeniKullaniciBilgisi),
]);
$sonucDizisi = json_decode( $sonuc->getBody()->getContents() , true );
//...devam
//dd( $sonucDizisi);
}
catch (RequestException $e) {
if ($e->hasResponse()) {
// Servise bağlanıldı ama HTTP hatası oluştu
// HTTP kodu: $e->getCode()
// Hata mesajı: $e->getMessage()
//Hata içeriği: json_decode( $e->getResponse()->getBody()->getContents() , true ) );
}
else {
// Servise bağlanılamadı, bağlantı hatası?
// Hata mesajı: $e->getMessage()
}
}
}
}
Döndürülen cevabın HTTP kodu 200 olduğu durumlarda, servis geriye JSON biçiminde gövdesi olan bir cevap döndürecektir. Diğer HTTP kodları için “Hata Kodları” bölümüne göz gezdirin. Cevap olarak gelen dizideki anahtarlar aşağıdaki tabloda gösterilmektedir:
| Anahtar | Kullanıldığı durum | Açıklama |
| hata | Her zaman | Boolean. İşlemin gerçekleşip gerçekleşmediğini gösterir. |
| onModulTarafindanDurduruldu | Her zaman | Boolean. İşlem bir hata nedeniyle gerçekleştirilemediyse, bunun ön modüllerden birisi tarafından engellenip engellenmediğini belli eder. |
| onModullerSonuc | Her zaman | Dizi. Her modül için, modül bilgilerini içeren bir eleman içerir. Yapısı aşağıda verilmiştir. |
| mesajlar | Ön modüller başarılı, ekleme işlemi başarısız olduğunda. | Dizi.Ekleme işlemi sırasında hatalı veri görülmesi durumunda hatalı veriler hakkındaki bilgileri içerir. Yapısı aşağıda verilmiştir. |
| arkaModulTarafindanDurduruldu | İşlem başarılı olduğunda | Boolean. İşlem gerçekleştirildikten sonra arka modüllerden birisinin hata döndürüp geriye kalan akışı engelleyip engellemediğini gösterir. |
| arkaModullerSonuc | İşlem başarılı olduğunda | Dizi. Her arka modül için, modül bilgilerini içeren bir eleman içerir. Yapısı aşağıda verilmiştir. |
| entryuuid | İşlem başarılı olduğunda | Yeni kullanıcının OpenLDAP için tekil tanımlayıcısı. |
| namingContext | İşlem başarılı olduğunda | Yeni kullanıcının OpenLDAP içinde yer aldığı “veri tabanı”. |
“onModullerSonuc” ve “arkaModullerSonuc” anahtarlarının değerleri konumundaki dizilerin yapısı şöyledir:
| Anahtar | Kullanıldığı Durum | Açıklama |
| hata | Her zaman | Boolean. Modüllerden birisinin hata döndürdüğünü gösterir |
| durduruldu | Her zaman | Boolean. Modüllerden birisinin döndürdüğü hata sonucu akışın durduğunu gösterir. |
| moduller | Her zaman | Dizi. Çalıştırılan her modülün sinif değerini ayrı bir anahtar olarak içerir. Değerler modüllerin sonuçlarını gösterir. Her değer “hata” (boolean) ve “mesaj” (string) anahtarlarını içeren bir dizidir. |
“mesajlar” anahtarının değeri konumundaki dizinin yapısı şöyledir:
| Anahtar | Kullanıldığı Durum | Açıklama |
| <servis çağrı anahtarı>[.<index>] | Ekleme işlemi sırasında veri hatasına neden olan her alan için | (string) mail/mobile gibi dizi kabul eden alanlar için, hataya neden olan verinin dizideki sırasını da (index) içerir. |
KYS servisleri aşağıda belirtilen durumlar haricinde HTTP 200 durum kodunu geriye döndürecektir. Sağlanan veri ile ilgili işlemlerden kaynaklı hatalarda da (veri sağlaması hataları gibi) HTTP 200 kodu döndürülecektir. Bu durumlarda cevap gövdesinde bulunan ilgili anahtarların (ör., “hata” anahtarı) değerlerinin kontrol edilerek veri hatası oluşup oluşmadığı kontrol edilmelidir. Geriye HTTP 200 kodunun döndürülmediği istisnai durumlar şöyledir:
HTTP 400 aşağıdaki durumlarda döndürülür:
entryuuid veya namingContext değerlerinin bir LDAP nesnesine karşılık gelmediği durumlarda.HTTP 401 aşağıdaki durumlarda döndürülür:
HTTP 403 aşağıdaki durumlarda döndürülür:
HTTP 500 aşağıdaki durumlarda döndürülür: