Из Core Java Vol II, chapter 9 Security, User Authentication

Transcription

1 Из Core Java Vol II, chapter 9 Security, User Authentication JAAS (The Java Authentication and Authorization Service) Део "authentication" односи се на утврђивање идентитета корисника, док део "authorization" придружује корисницима дозволе (енг. permissions). JAAS изолује Јава апликације од конкретне технологије која се користи за имплементирање аутентификације. Између осталог, подржава UNIX login, NT login, Kerberos authentication, certificate-based authentication. Након што је корисник аутентификован, могуће је придружити му скуп дозвола. Нпр. овде дајемо (енг. grant) Харију одређени скуп дозвола које други корисници немају: grant principal com.sun.security.auth.unixprincipal "harry" { permission java.util.propertypermission "user.*", "read"; ; Класа com.sun.security.auth.unixprincipal проверава име UNIX корисника који извршава текући програм. Њен метод getname() враћа UNIX корисничко име, а ми проверавамо да ли је то име "harry". LoginContext се користи како би се security manager-у омогућило да провери овакве grantнаребе. Следи костур login кôда: try{ System.setSecurityManager(new SecurityManager()); LoginContext context = new LoginContext("Login1"); // defined in JAAS configuration file context.login(); // get the authenticated subject Subject subject = context.getsubject(); context.logout(); catch(loginexception exception){ // thrown if login was not successful exception.printstacktrace(); Сада subject означава особу која је аутентификована. Параметар "Login1" конструктора класе LoginContext односи се на истоимени ентитет у JAAS конфигурационом фајлу.

2 Следи пример једноставног конфигурационог фајла: Login1 { com.sun.security.auth.module.unixloginmodule required; com.whizzbang.auth.module.retinascanmodule sufficient; ; Login2 { ; Наравно, JDK не садржи биометријске login модуле. У пакету com.sun.security.auth.module налазе се следећи модули: UnixLoginModule NTLoginModule Krb5LoginModule JndiLoginModule KeyStoreLoginModule Login policy састоји се од секвенце login модула, од којих је сваки означен као required, sufficient, requisite или optional. Значење ових кључних речи одређено је следећим алгоритмом: 1. модули се извршавају редом, а стаје се када успе sufficient модул, не успе requisite модул или се дође до краја листе модула 2. аутентификација је успешна ако успеју сви required и requisite модули или се не изврши ниједан од њих или бар један sufficient или optional модул успе. Login аутентификује subject који може имати више principal-а. Принципал описује неко својство subject-a попут username, group ID, role. Као што се може видети из grant-наредбе, принципали одређују дозволе. com.sun.security.auth.unixprincipal описује Unix login name, а UnixNumericalGroupPrincipal може тестирати чланство у Unix групи. Синтакса grant-клаузе за тестирање принципала је: grant principalclass "principalname" Нпр. grant com.sun.security.auth.unixprincipal "harry" Када је корисник улогован, покренемо, у посебном access control context-у, кôд који захтева проверу принципала. Статички метод doas() или doasprivileged() користи се покретање нове PrivilegedAction чији метод run() извршава кôд.

3 Оба ова метода извршавају акцију позивањем метода run() објеката класе која имплементира интерфејс PrivilegedAction, користећи дозволе subject-ових принципала: PrivilegedAction<T> action = new PrivilegedAction(){ public T run(){ // run with permissions of subject principals ; T result = Subject.doAs(subject, action); // or Subject.doAsPrivileged(subject, action, null); Уколико акције могу избацити checked изузетке, уместо PrivilegedAction имплементира се интерфејс PrivilegedExceptionAction. Разлика између метода doas() и doasprivileged() је суптилна. Метод doas() започиње са текућим access control context-ом, док doasprivileged()започиње са новим контекстом и омогућује нам да раздвојимо дозволе login кôда и "business logic". У нашем примеру, login кôд има дозволе: permission javax.security.auth.authpermission "createlogincontext.login1"; permission javax.security.auth.authpermission "doasprivileged"; Аутентификовани корисник има дозволу: permission java.util.propertypermission "user.*", "read"; Да смо, уместо doasprivileged() користили doas(), login кôд би такође морао да има ту дозволу. Пример AuthTest демонстрира како ограничити дозволе само на одређене кориснике. Програм AuthTest аутентификује корисника, а затим извршава једноставну акцију која дохвата системско својство. Како би овај програм радио, кôд за login и акцију се упакује у два одвојена JAR фајла: javac *.java jar cvf login.jar AuthTest.class jar cvf action.jar SysPropAction.class Ако погледате policy фајл, видећете да UNIX корисник са именом harry има дозволу да чита све фајлове. Промените harry у своје корисничко име. Затим извршите команду: java -classpath login.jar:action.jar -Djava.security.policy=AuthTest.policy -Djava.security.auth.login.config=jaas.config AuthTest

4 Под Windows-ом промените Unix у NT у оба фајла: AuthTest.policy (овде заправо треба NTUserPrincipal, а не само NTPrincipal) и jaas.config и користите тачка-запету да раздвојите JAR фајлове: java -classpath login.jar;action.jar Програм треба да прикаже вредност својства user.home. Међутим, уколико промените login name у фајлу AuthTest.policy, требало би да буде избачен security exception јер више немате потребну дозволу. ОПРЕЗ: Будите пажљиви да тачно пратите ове инструкције јер се веома лако греши. API... JAAS Login Modules Примером ће бити илустровано - како имплементирати сопствени login модул - како имплементирати role-based аутентификацију. Коришћење сопственог login модула је корисно ако се login информације чувају у бази података. Чак и ако сте срећни са подразумеваним модулом, проучавање овог ће Вам помоћи да разумете опције JAAS конфигурационог фајла. Role-based аутентификација (аутентификација заснована на улогама) је кључна за руковање великим бројем корисника. Било би непрактично сместити имена свих легитимних корисника у policy фајл. Уместо тога, login модул треба да мапира кориснике у улоге попут "admin" или "HR" и дозволе треба да буду базиране на овим улогама. Један од задатака login модула је да попуни скуп принципала аутентификованог subject-а. Ако login модул подржава улоге, он додаје Principal објекте који описују улоге. Јавина библиотека не обезбеђује посебну класу за то, па пишемо сопствену (SimplePrincipal). Ова класа просто чува пар опис/вредност, попут role=admin. Њен метод getname() враћа тај пар, тако да можемо да додамо role-based дозволу у policy фајл: grant principal SimplePrincipal "role=admin" { Наш login модул тражи кориснике, шифре и улоге у текстуалном фајлу који садржи линије облика: harry secret admin carl guessme HR Наравно, у реалистичном login модулу ове информације би требало чувати у бази података.

5 Метод checklogin() класе SimpleLoginModule проверава да ли корисничко име и шифра одговарају неком од слогова из password-фајла. Ако је то случај, додаје два SimplePrincipal објекта скупу принципала subject-a: Set<Principal> principals = subject.getprincipals(); principals.add(new SimplePrincipal("username", username); principals.add(new SimplePrincipal("role", role); Остатак класе SimpleLoginModule је праволинијски. Метод initialize() прима: - subject који се аутентификује - handler за добијање login информација - sharedstate мапу која се може користити за комуникацију између login модула - options мапу која садржи парове име/вредност постављене у login конфигурацији. Нпр. конфигуришемо наш модул са: SimpleLoginModule required pwfile="password.txt"; Login модул дохвата pwfile подешавања из мапе options. Он не дохвата корисничко име и шифру јер је то посао посебног handler-а. Овакво раздвајање нам омогућује да користимо исти модул без бриге о томе да ли су login информације добијене из GUI дијалошког прозора, у конзоли или из конфигурационог фајла. Handler се задаје приликом конструисања LoginContext, нпр. LoginContext context = new LoginContext("Login1", new com.sun.security.auth.callback.dialogcallbackhandler()); DialogCallbackHandler приказује једноставан GUI дијалошки прозор за добијање корисничког имена и шифре. com.sun.security.auth.callback.textcallbackhandler добија информације из конзоле. Међутим, у нашој апликацији имамо сопствени GUI за добијање корисничког имена и шифре. Правимо једноставни handler који просто чува и враћа те информације. Handler има само један метод handle(), који процесира низ Callback објеката. Известан број предефинисаних класа, попут NameCallback и PasswordCallback имплементира интерфејс Callback. Можемо такође додати сопствену класу, попут RetinaScanCallback. Кôд за handler је помало неугледан јер мора да анализира тип callback објеката: public void handle(callback[] callbacks){ for(callback callback: callbacks){ if(callback instanceof NameCallback) else if(callback instanceof PasswordCallback) else

6 Login модул припрема низ callback-ова који му је потребан за аутентификацију: NameCallback namecall = new NameCallback("username: "); PasswordCallback passcall = new PasswordCallback("passwd: ", false); callbackhandler.handle(new Callback[] {namecall, passcall); Затим дохвата информације из callback-ова. Програм JAASTest приказује форму за уношење login информација и имена системског својства. Ако је корисник аутентификован, вредност својства се добија у PrivilegedAction. Као што се може видети у policy фајлу, само корисници са улогом admin имају дозволу да читају својства. Као и за претходни пример, неопходно је раздвојити login и кôд за акцију. Креирају се два JAR фајла: javac *.java jar cvf login.jar JAAS*.class Simple*.class jar cvf action.jar SysPropAction.class Затим се програм извршава са: java -classpath login.jar:action.jar -Djava.security.policy=JAASTest.policy -Djava.security.auth.login.config=jaas.config JAASTest Могуће је подржати комплекснији двофазни протокол где се login commit-ује ако су сви модули у login конфигурацији успели. За више информација погледати login module developer s guide (стари URL: API