Çok Katmanlı WEB Tabanlı Uygulamalarda Yetkilendirme Problemi

Transkript

1 Çok Katmanlı WEB Tabanlı Uygulamalarda Yetkilendirme Problemi Yenal Göebakan cybersoft, Ankara, TURKEY Abstract Yetkilendirme amaçlı gelitirilmi bulunan çeitli çözümler kaynaa eriim hakkı kararını tek bir boyuta göre vermektedir; kullanıcının kimlii veya organizasyondaki rolu gibi. Oysa özellikle büyük ölçekli WEB tabanlı merkezi uygulamalarda eriim yetkisi kararının birden çok ve karmaık boyutlar dikkate alınarak verilmesi gerekmektedir (veri, kullanıcının hangi organizasyonda olduu, islem miktari vb.) Bu bildiride yetkilendirme problemi için birden çok boyutu dikkate alan, gerektiinde eriim hakkı kararı için i mantıı kurallarının kullanılabildii, fakat bunun i mantıı programlarının dıında ayrıca sistematik bir ekilde yapılabildii, tüm yetkilendirme ilemlerinin kayit altina alınabildii ve güvenlik gereksinimlerinin belirledii tanıma yöntemi ile entegre çalıan ve cybersoft tarafından gelitirilmi bir çözüm olan cybersoft Authentication & Authorization Service (CSAAS) anlatılmaktadır. 1. Giri Günümüz uygulamalarında kullanılan basit "kaynak - eriim hakkı" yetkilendirme çözümü i gereksinimlerinin her geçen gün karmaıklaması sonucu yetersiz hale gelmi, karmaık yetkilendirme gereksinimleri programların içerisine gömülmü ek kodlama ile salanmaya çalıılmı, bu ise anlaılması ve bakımı zor programlara sebep olmutur. Özellikle kullanıcı sayısındaki fazlalık, kullanıcı tiplerindeki çeitlilik ve buna balı olarak yetkilendirme ihtiyaçlarındaki karmaıklık WEB tabanlı Internet uygulamalarında yeni çözüm arayılarına yol açmıtır. Yetkilendirme çözümü kapsamında kullanılan Rol Tabanlı Eriim Kontrolü (RBAC - Role Based Access Control) [1], Eriim Kontrol Listeleri (ACL - Access Control List) veya Kaynak Eriim Kontrolü (RAD - Resource Access Decision) [2] gibi çözümler tek balarına büyük ölçekli uygulamalarda yetersiz kalmaktadır. Genel olarak sistem tarafından dorulanmı (Authenticated) kullanıcıların yetkilendirme modeli basit olarak aaıdaki ekilde tanımlanabilir : Kullanıcı (Kaynak, lem) Bu modelde Yetkilendirme ilemi kullanıcı ile kaynak ve o kaynak üzerinde tanımlanmı ilem çiftleri arasında bir iliki olarak tanımlanır. Yetki sadece kaynak eriimi için tanımlanırsa ilem bo olabilir. Yetkilendirme modeli üç temel varsayım üzerine dayanır : 1. Güvenli sistem : (Kaynak, lem) çiftine yetki sadece ve sadece kullanıcı ile arasında tanımlanan iliki varsa geçerlidir, iliki yoksa yetkilendirme yoktur. 2. Gereken en az yetki : Kullanıcıya sadece gerekli olan en alt seviye yetki verilir. 3. Yetkilendirme sistemi bilinci : Uygulamalar yetkilendirme ihtiyaçları için bilinçli olarak bu modeli kullanır. Uygulamalar modeli kullanmadan yetkilendirme için karar vermezler. Yetkilendirme konusunda bu bildiride önerilen çözümü detaylı olarak ortaya koymak için tipik bir uygulama ve yetkilendirme ihtiyacı bir sonraki bölümde anlatılmıtır. Daha sonra yetkilendirme modelinde belirtilen ilikiyi tanımlayan iki yaygın çözüm anlatılmı ve özellikleri verilmitir. Bir sonraki bölümde önerilen CSAAS sistemi anlatılarak yetkilendirme problemi için gelitirilen çözüm anlatılmı ve sonuç bölümünde sistemin gelimesi için öneriler sıralanmıtır.

2 2. Örnek Problem WEB tabanlı uygulamalarda yetkilendirme problemi; uygulamaların ve verinin merkezi olmasından kaynaklanan tüm yetkilendirme kararlarının merkezi olarak alınması ihtiyacı nedeniyle daha fazla önem arzeder. Yetkilendirme kararlarının dayanaı olan kullanıcı kimlii, organizasyon, lokasyon gibi bilgiler tüm sistemi kapsayacak ekilde yetkilendirme sistemi içerisinde kullanılmalıdır. Tanımlanan örnek problem bir bankanın kredi kullandırım sistemi ile ilgilidir. A Bankası belirli bir miktarı aan kredileri (Kbüyük) genel merkez, bu miktarın altındaki kredileri ise ubeleri aracılıı ile müterilerine kullandırmaktadır. Kredi bavuruları her iki durumda da ubelere yapılmakta ve orada kredi miktarına göre deerlendirilmekte veya genel merkeze yönlendirilmektedir. ubelerde deerlendirilen krediler memur (), ef (B) ve yönetici (By) onayı ile sonuçlandırılmaktadır. Genel merkeze yönlendirilen deerlendirmeler ise ube yöneticisi onayı ile Merkez Krediler müdürü (Mm) tarafından sonuçlandırılmaktadır. A Bankasının organizasyon yapısı aaıdaki ekilde tanımlanabilir : Mm By By By Doal olarak yukarı doru bir yetki hiyerarisi mevcuttur. Memur ve eflerin yapabildii tüm ilemleri yöneticiler de yapabilmektedir. Bir sonraki bölümde bahsedilen yetkilendirme ihtiyaçları için kullanılabilecek iki sistemin (RBAC ve RAD) nasıl bir çözüm sundukları ve eksiklikleri belirtilmitir. 3. Rol Tabanlı Eriim Kontrolü (RBAC) 3.1. Rol Tabanlı Eriim Kontrolü (RBAC) Rol Tabanlı Eriim Kontrolü (RBAC) yetkilendirme çözümü, giri bölümünde bahsedilen modeldeki Kullanıcı (Kaynak, lem) ilikisini kiiler yerine organizasyona dayalı, rol olarak adlandirabileceimiz genel yapılar üzerine kurmutur. Bu çözümün dayandıı temel ilke organizasyonel yapıya dayalı rollerin, kiilerin aksine, kalıcı olduu ve zaman içerisinde çok az deitiidir. Roller; organizasyonel birimleri, sorumlulukları, yapılan belirli ileri tanımlayabilir ve genelde aaç yapısında oluturulurlar. Kullanıcılar birden fazla role ait olabilirler ve yetkiler de bu rollere verilir. Her bir rol birden fazla kaynak ve ilem yetkisini tanımlayabilir. RBAC çözümünde yukarıdaki iliki aaıdaki ekilde yeniden yazılabilir : B B B Kullanıcı Roller (Kaynak, lem) Bu yapida kiiler bir veya birden fazla role atanirlar ve yetkiler de bu rollere verilir. Böylece, rollerin deimeyecei veya daha az deiecei öngörülerek kullanıcılar deise bile yetkilendirme yapısını deitirmeye gerek olmayacaktır. ekil 1 Kredilerin hangi ubeye gidecei müteri adresi ile ilgilidir. Müteriler sadece balı oldukları ubeye kredi bavurusunda bulunabilirler. ubeler sadece kendi müterileri ile ilgili kredi bilgilerini görebilirler, dier ubelerin kredi ilemleri ve bu ilemler ile ilgili bilgilere eriemezler. ubelerde personel durumuna göre ef veya yöneticilik baka servislerin ef veya yöneticileri tarafından yapılabilmektedir. RBAC çözümünde roller hiyerarik bir yapıda oluturulurlar ve bir üst kademedeki rolun yetkileri altindaki rol tarafindan otomatikman sahip olunur. [4] ekil 2 de tipik bir rol aacı gösterilmitir. Bu aaçta tanımlanan roller örnek problemde bahsedilen pozisyonlarla uyumludur. Rol aacının kök bölümünde memur rolü tanımlanmıtır. Bu role tipik bir kullanıcının sahip olduu yetkiler atanmıtır. 1. Giri bölümünde bahsedilen modeldeki 2. kural gerei bu role memur rolünün sahip olması gereken en az yetki verilir.

3 Daha sonra iki ayrı birimin ef rolleri gösterilmitir. Örnek olarak muhasebe efi rolüne, muhasebe efinin yapacaı ilemler ile ilgili yetkiler verilirken, kredi efi rolüne kredi ilemleri ile ilgili yetkiler verilir. Bu roller ayni zamanda memur rolüne verilen yetkilere de sahip olurlar. Bu RBAC çözümünün tanımından gelen bir özelliktir [4]. Kredi Müdürü Kredi efi Memur Kullanıcılar roller için belirlenmi yetkilere, bu rollere atanarak sahip olurlar. Muhasebe müdürü rolüne atanmı bir kullanıcı sırasıyla memur, muhasebe efi ve muhasebe müdürü rollerine atanmı tüm yetkilere sahip olur Böylece yetkiler bir hiyerari içerisinde yönetilmi olur. Müdür kadrosundaki kullanıcı ise, bu örnekte, hem kredi müdürü hem de muhasebe müdürü rollerine atanarak her iki rolün yetkilerine de sahip olur. Roller kullanıcılara belirli bir süre için de verilebilir. RBAC çözümünün bir ileriki aamasında kullanıcılar iki farklı gruptaki rollere atanmaktadır. Bunlardan ilki kullanıcının sahip olduu rolleri, dier ise sahip olduu roller içerisinde eksiltilecek rolleri gösterir. Böylece muhasebe müdürü rolüne atanan bir kullanıcıdan muhasebe efi yetkileri alınabilir RBAC Deerlendirme Muhasebe Müdürü Muhasebe efi ekil 2. Ters (Inverted) Role Aacı RBAC çözümü örnek problemde bahsedilen bir çok sorunu çözmektedir. Yetkilerin bir hiyerari içerisinde yönetilebilir ve devredilebilir olması çok önemli bir avantajdır. zine çıkan personelin sahip olduu rollere yerine vekaleten bakan personel atanarak kolayca ilemler kesintisiz devam edebilir. Yönetici, ef ve Memur kadrolari için yetkiler tanımlanabilir ve bu tüm organizasyon içerisinde standard olarak kullanılabilir. Terfi eden kullanıcılar yeni rollere kolaylıkla atanarak yeni pozisyonlarının gerektirdii yetkilere sahip olurlar. Sistem içerisinde gelitirilen yeni uygulamalar (kaynak ve ilem çiftleri) kolaylıkla roller ile eletirilerek uygun yetkilerle kullanıma alınabilirler. Tüm kullanıcılara tek tek yetki vermeden sadece rollere yetki tanımlayarak bu ilem yapılabilir. WEB tabanlı uygulamaların hepsinde görülen merkezi program anlayıı gerei tüm organizasyonun merkezi olarak tek bir yapıda tutulması, RBAC çözümünün çok önemli bazı uygulama ihtiyaçlarını karılamamaktadır. Örnek problemimizde tüm ubelerin ef kadrosundaki kullanıcıları ef rolüne atanmı olup bu rolün yetkilerine sahiptir. Fakat, ubenin sadece kendi alanı içerisindeki müteriye hizmet etme koulu RBAC tarafından salanamaz. Sistem yetkileri sadece rol tabanlı olarak tanımlamıtır. Oysa i ihtiyacı bazı ilemler için rol dıında baka bilgilere göre yetki kararının verilmesini gerektirmektedir ve RBAC buna kendi tanımı içerisinde bir çözüm sunamamaktadır. efe verilen kredi onay yetkisi de sınırlıdır. Kredi miktarının büyüklüüne göre ef rolünün sahip olduu onay yetkisi geçersiz olabilmektedir. RBAC yetkilendirme konusunda çok önemli bir gelime olmasına karın yukarıda belirtildii gibi i mantıı bilgisi gereken konularda yetersiz kalmaktadır. Bu eksiklik genelde i mantıı içerisine konulan program parçaları ile giderilmekte olup bakımı zor ve anlaılmaz, düük performanslı programlara sebep olmaktadır 4. Kaynak Eriim Kontrolü (RAD) 4.1. Kaynak Eriim Kontrolü (RAD) Kaynak Eriim Kontrol (RAD) [2] çözümü yetkilendirme ihtiyacı için gereken programlamanın i mantıı programlarının içerisine konulmadan gerçekletirilmesini salamak için gelitirilmitir. Uygulamaların istedii hassasiyet ve incelikte yetkilendirme kararlarının alınmasına imkan vermektedir. RBAC çözümünün en büyük eksiklii olan uygulama alanına ait veri ve i mantıını yetkilendirme kararlarını alırken kullanabilir. RAD çözümünün bir dier avantajı da yetkilendirme kararı için uygulama sistemi dıındaki kaynaklardan (geçi kartları, legacy sistemler vb.) yararlanabilmesidir. Bu özellii sayesinde PKI, biosecurity gibi çözümler kolaylıkla entegre edilebilir. RAD, 1. Giri bölümünde tanımlanan modelin 3. özelliine dayanarak uygulamaların her istek (bir kaynak üzerinde tanımlanmı bir ilemi gerçekletirme

4 istei) öncesi yetkilendirme konusunda bir karar almasını öngörür. Bu istek i mantıı programlarının içine gömülü olmayıp, genel olarak sistem tarafından otomatik olarak yapılan bir ilem olarak düünülmelidir. RAD çözümü aaıdaki gibi tanımlanabilir : Yetkilendirme istei ve uygulamalara baımlı, özel i ihtiyaçları tarafından belirlenen politikalar. Her iki halde de yetki politikası programları sisteme kolayca eklenebilir ve çıkarılabilir. Yetki politikaları, yetkilendirme kararları verirken ihtiyaç duyacakları verileri iki ekilde elde ederler. Uygulama bazlı veriler RAD tarafından otomatik olarak politika programına geçirilir. Sistem bazında alınacak veriler ile dı sistemlerden salanacak veriler ise yetki politikası programları tarafından salanır (JDBC, Http etc. ) Gezgin Uygulama RAD Servisi Yetkilendirme Kararı 4.2. RAD Deerlendirme RAD çözümü özellikle uygulama alanı verisi gereken yetkilendirme kararları için ideal bir çözümdür. Istenildii kadar hassasiyetle yetkilendirme kararları alınabilir. ekil 3. ekil 3. de WEB tabanlı bir uygulama için RAD kullanımı gösterilmitir. Gezgin kullanıcının uygulamalara eritii arayüzdür. Sadece sunum mantii gezgin üzerinde olup i mantıı uygulama olarak gösterilen ara katman üzerinde gelitirilmitir. Gezgin tarafından yapılan tüm uygulama servis çarıları uygulama katmanı tarafından önce otomatik olarak RAD servisine gönderilir. RAD servisi kendi içerisinde yetkilendirme kararını vererek uygulamaya döner. Merkezi uygulama, RAD dan gelen cevap üzerine talep edilen servisi çalıtırır veya çalıtırmaz. Yukarıdaki sistemde belirtilmesi gereken en önemli konu yetkilendirme kararlarının uygulama tarafından otomatik olarak RAD servisine gönderildiidir. mantıı programlarının içerisine ek program koymaya gerek yoktur. RAD sisteminin yetkilendirme kararlarını verebilmesi için uygulama verilerine ve/veya dı sistem verilerine ihtiyacı olabilir. Uygulama verilerinin bir ekilde RAD sistemine geçirilmesi gerekmektedir. Dı sistem verileri ise RAD tarafından toplanır. RAD sistemleri, bir önkoul olmamasına ramen genel olarak CORBA veya RMI servisi olarak gelitirilirler. Dinamik olarak yüklenen program kütühanesi (DLL) olarak da gelitirilmi sürümleri mevcuttur. Yetkilendirme kararları RAD içerisine konulan Yetki Politikasi (Security Policy) programları ile salanır. Bu politikalar genel olarak ikiye ayrılır; uygulamalardan baımsız sistemin genelinde kullanılan ortak politikalar RBAC çözümünün yetersiz kaldıı, ubenin sadece kendi bölgesindeki müterilere hizmet edebilmesi yetkisi, RAD kullanılarak kolaylıkla çözümlenebilir. Kredi miktarlarına göre memur veya efin onaylayabilecei krediler de bu çözüm ile basit bir yetki istei ile belirlenir. Günün saati, ubenin corafi konumu, ait olduu bölge, müterinin geçmi ilemleri, yapılan ilemin büyüklüü gibi verilerin zorunlu olarak kullanıldıı yetkilendirme kararları RAD bünyesinde standard bir yöntemle çözümlenebilir. ubelerin sadece kendi yaptıkları kredi anlamalarını görmeleri, eflerin sadece belirli miktarın altındaki kredi anlamalarını görebilmeleri ve genel merkezin tüm anlamaları görebilmesi RAD çözümü ile entegre çalıacak ekilde gelitirilecek bir filtreleme mekanizmasi ile mümkün olabilir. RAD ın esnek yapısı gelitirme ve bakım zorluunu da beraberinde getirmektedir. RBAC ın sunduu genel bir yetkilendirme yapısı sunmadıı için i mantıı ve yetki sisteminde yapılacak deiikliklerin RAD sistemine yansıtılması balı baına bir itir. Özellikle uygulama veri yapılarının deiimine karı RAD çok hassastır. 5. CSAAS Çözümü cybersoft firması özellikle enterprise ölçekli WEB tabanlı uygulamalar gelitirmekte olup bir süredir bahsedilen yetkilendirme problemini giderecek, bu yetkilendirme konusunda tüm projelerde kullanılacak, bakımı ve kullanımı kolay bir araç arayıında idi. Bu amaçla firma bünyesinde çeitli yazılım mimarileri ve çözümler hakkında aratırmalar yapılmı, teorik ve

5 pratik bir çok çözüm incelenmitir. Önceki bölümlerde bahsedilen RBAC ve RAD gibi genel kabul görmü çözümler çeitli projelerde kullanılmı fakat istenilen kalitede bir sonuç elde edilememitir. Bunun üzerine RBAC ve RAD çözümlerini birletiren, enterprise ölçekli uygulamaların ihtiyaçlarına cevap veren, yüksek performanslı bir yetkilendirme çözümü olan CSAAS tasarlanarak gelitirilmitir. u anda 3 büyük ölçekli projede (ki bunlardan biri Internet uygulaması dieri de 10,000 kullanıcılı bir uygulamadır) kullanılmakta olup bir program dahilinde yeni özellikler eklenmektedir. [6] Authorizati on CSAAS mimarisi aaıda verilmitir : Access Decision Politika hesaplayici Bulma Sonuç Karar ekil 4. CSAAS mimari olarak 3 temel parçadan oluur. 1. Dinamik Veri Servisi : Yetkilendirme kararlarını verecek politikaların ihtiyaç duyacakları ve uygulamadan gelmeyen harici verilere CSAAS bünyesinden kolaylıkla eriilmesini salayan servis. Mevcut sürümde JDBC uyumlu veri tabanları, LDAP ve text kütüklere eriim salanmaktadır. 2. Politika Hesaplayıcı Belirleme Servisi : Yetkilendirme istenilen servis için, yani (kaynak, ilem) ikilisi için hangi yetki politikası program veya programlarının çalıtırılacaını belirleyen servis. CSAAS de birden fazla politika yetkilendirme için kullanılır. Böylece küçük, tekrar kullanılabilir politikalar yazmak mümkündür. 3. Karar Servisi : Birden fazla politika hesaplama programından olumu yetkilendirme servisleri için politika kararlarını toplayarak onlardan sonuç kararı üreten servistir. AND, OR ve MAJOR karar vericileri CSAAS içerisinde hazır olarak sunulmakadır. CSAAS bünyesinde yetkilendirme politikası programları Java Script programları, Java sınıfları ve P ol iti ka H es ap Di na m ik V er i D A S K ay na k CSAAS a özgü bir ekilde gelitirilmi declarative kurallar olmak üzere 3 ekilde gelitirilebilir. Örnek bir yetki politikası programı olarak RBAC politika programı gösterilebilir. CSAAS içerisinde RBAC bir politika olarak tasarlanmı ve gelitirilmitir. Uygulamalardan kullanıcı ID sini veri olarak alır, dinamik veri servisinden o kullanıcıya ait rolleri ve roller için tanımlanmı yetkileri alır ve istenilen ilem için yetki kararını verir. Uygulamalar yetkilendirme isteklerini, i mantıı programlarına birey eklemeden veya tek bir yerde ekleyerek CSAAS a yönlendirirler. ekil 4 ün en solundaki blok olarak gösterilen kısım bu istekleri alır ve uygulamadan gelen verilerle birlikte politika hesaplayıcı belirleme servisine geçirir. CSAAS ın bu bölümü RMI servis olarak gelitirilmitir. Politika hesaplayıcı belirleme servisi tarafından belirlenen politik programları çalıtırılır ve sonuçları karar servisi tarafından birletirilerek yetki kararı oluturulur. Yetki politikaları programları çalıırken gerek duyduklari verileri dinamik veri servisinden alırlar. Örnek problemde belirtilen her ubenin sadece kendi bölgesine ait kredi bilgisine erimesi yetki ihtiyacı CSAAS kullanılarak kolaylıkla giderilebilir. Bu amaçla gereken yetki politikası programı declarative bir kural olarak tanımlanır ve sisteme tanıtılır. Gerekli ek tanımlamalar da yapıldıktan sonra her bir kredi tanımlama istei CSAAS a otomatik olarak yönlendirilir. Önce RBAC politikasından geçen istek, kullanıcının ef veya yönetici rollerine sahip olma durumuna göre yetkilendirilir veya reddedilir. Bahsedilen senaryo RBAC ve RAD yetkilendirme servislerinin dorudan adresleyemedii bir durumun i mantıı programlarına ekleme yapılmadan çözülmesini göstermek açısından bir örnektir. CSAAS servisinin mevcut sürümü Java RMI teknolojisi kullanılarak gelitirilmitir. Böylece hemen tüm sistemlerde (UNIX, Linux, MS Windows) çalıması mümkündür. Ayrıca ugulama programlarının gelitirilme ortamına baımlı deildir, Java, CORBA, J2EE, Servlet gibi ortamlarda gelitirilmi uygulamalar tarafından kolaylıkla kullanılabilir. Kullanıcı dorulama servisi CSAAS in içerisinde deitirilebilir bir modul olarak tasarlanıp gelitirilmitir. Günümüz ihtiyaçlarına göre yeni kullanıcı tanımlama modülleri (smartcard, biolojik kullanıcı dorulama teknikleri vb.) kolaylıkla sisteme eklenebilir. u anda kullanılan dorulama modülü JDBC uyumlu bir veri tabanı veya LDAP üzerinde tutulan

6 kullanıcı ID ve ifre (password) ikilisinin kullanıcıdan alınarak kontrol edilmesi yöntemini kullanmaktadır. CSASS servisi, mimari olarak çeitli katmanlardan olumutur. RBAC Meta Data Management Bu katmanlardan Cache Yönetim katmanı henüz gelitirilmemitir. 6. Sonuç CSAAS RAD Cache Management Resource Management Administrative Services Bu bildiride özellikle büyük ölçekli WEB tabanlı uygulamalar için kullanılabilecek olan bir yetkilendirme çözümü olan CSAAS anlatılmıtır. RBAC ve RAD çözümlerinin problemleri belirtilmi ve bu çözümlerin eksiklikleri örnek bir problem aracılıı ile ortaya konulmutur. Günümüz uygulamalarının daha çok WEB tabanlı olması ve programların merkezi olarak çalıması bahsedilen problemlerin daha da büyümesine sebep vermitir. Ayrıca her iki çözüm de sistem yönetimi ve bakım ihitiyacı olarak çok büyük yükler getirmektedir. Bahsedilen problemleri giderecek, bakımı kolay, enterprise ölçekli uygulamaların ihtiyaç duyduu peformans deerini yakalayabilecek ve uygulamalar tarafından kolayca kullanılabilecek bir yetkilendirme sistemi olan CSAAS, cybersoft tarafından tasarlanıp gelitirilmitir. Tüm yetkilendirme ihtiyaçlarına cevap verecek bir servis olarak gelitirilen CSAAS, kullanılması halinde uygulamalar için kritik bir parça olmaktadır. Bu yüzden mutlaka load balance ve failover özellikleri eklenmelidir. Ayrica performansı artırmak için cache yönetim katmanı gelitirilmelidir. Referans [1] Ravi S. Sandhu Role Based Access Control [2] OMG Specification RAD v1.0 [3] Role-Based Access Control Models (RBAC) : Fetures and Motivations, David Ferrailo et Ali.,Computer Security Applications Conference, December 1995 [4] Inheritance Properties of Role Hierarchies, W.A.Jansen, National Instittute of Satandards and Technology [5] Internet Resource Access Control, The Butterfly Model, NorCom WhitePaper [6]CSAAS, cybersoft Authentication & Authorization Service, 2000, WhitePaper