Programowanie z użyciem interfejsów API zabezpieczeń programowych na potrzeby aplikacji WWW
Poniższe informacje umożliwiają programowe zabezpieczenie interfejsów API na potrzeby aplikacji WWW.
Przed rozpoczęciem
Zabezpieczenia programistyczne są używane przez aplikacje używające zabezpieczeń, gdy same zabezpieczenia deklaratywne nie wystarczają do wyrażenia modelu zabezpieczeń aplikacji.
Funkcje API wylogowania, logowania i uwierzytelniania są nowe w przypadku serwletu Java™ Servlet 3.0 w tej wersji serwera WebSphere® Application Server.
Na potrzeby uwierzytelniania WWW można skonfigurować kilka opcji określających sposób interakcji klienta WWW z chronionymi i niechronionymi jednolitymi identyfikatorami zasobów (URI). Ponadto można określić, czy serwer WebSphere Application Server będzie wyzwadzał klienta WWW w celu uzyskania podstawowych informacji uwierzytelniających, jeśli uwierzytelnianie certyfikatu dla klienta HTTPS nie powiedzie się. Więcej informacji można znaleźć w artykule Wybieranie mechanizmu uwierzytelniania.
Jeśli używana jest metoda isUserInRole, w deskryptorze wdrażania należy zadeklarować element security-role-ref z elementem podrzędnym role-name zawierającym nazwę roli przekazywaną do tej metody lub użyć adnotacji @DeclareRoles. Ponieważ rzeczywiste role są tworzone na etapie składania aplikacji, jako nazwy roli można użyć roli logicznej i przekazać asemblerowi wystarczająco dużo wskazówek w opisie elementu security-role-ref, aby mógł powiązać tę rolę z rolę rzeczywistą. Podczas asemblacji asembler tworzy podelement role-link w celu powiązania nazwy roli z rzeczywistą rolą. Tworzenie elementu security-role-ref jest możliwe, jeśli używane jest narzędzie Assembly Tool, takie jak Rational® Application Developer. Element security-role-ref można także utworzyć na etapie składania za pomocą narzędzia Assembly Tool.
Procedura
- Dodaj wymagane metody zabezpieczeń w kodzie serwletu.
- Utwórz element security-role-ref z polem role-name . Jeśli element security-role-ref nie został utworzony na etapie programowania, musi zostać utworzony na etapie składania.
Wyniki
Przykład
<security-role-ref>
<description>Provide hints to assembler for linking this role
name to an actual role here<\description>
<role-name>Mgr<\role-name>
</security-role-ref><security-role-ref>
<description>Hints provided by developer to map the role
name to the role-link</description>
<role-name>Mgr</role-name>
<role-link>Manager</role-link>
</security-role-ref>public void doGet(HttpServletRequest request,
HttpServletResponse response) {
....
// to logoff the current user
request.logout();
// to login with a new user
request.login(“bob”,”bobpwd”)
// to get remote user using getUserPrincipal()
java.security.Principal principal = request.getUserPrincipal();
String remoteUser = principal.getName();
// to get remote user using getRemoteUser()
remoteUser = request.getRemoteUser();
// to check if remote user is granted Mgr role
boolean isMgr = request.isUserInRole("Mgr");
// use this information in any way as needed by
// the application
....
}public void doGet(HttpServletRequest request,
HttpServletResponse response) {
....
// to logout the current user. If you are not already authenticate, then no need to call the logout() method.
request.logout();
// to login with a new user
request.login(“utle”,”mypwd”)
// the user utle subject now set on the thread and the LTPA SSO cookie is set in the response
....
}public void doGet(HttpServletRequest request,
HttpServletResponse response) {
....
// to logout the current user. If you are not already authenticate, then no need to call the logout() method.
// to login with a new user
request.authenticate(response);
// the new user subject now set on the thread and the LTPA SSO cookie is set in the response
....
}@javax.annotation.security.DeclareRoles("Mgr")
public void doGet(HttpServletRequest request,
HttpServletResponse response) {
....
// to get remote user using getUserPrincipal()
java.security.Principal principal = request.getUserPrincipal();
String remoteUser = principal.getName();
// to get remote user using getRemoteUser()
remoteUser = request.getRemoteUser();
// to check if remote user is granted Mgr role
boolean isMgr = request.isUserInRole("Mgr");
// use this information in any way as needed by
// the application
....
}W następującym przykładzie przedstawiono aplikację WWW lub serwlet korzystający z modelu zabezpieczeń programowych.
W tym przykładzie zaprezentowano tylko jedno z wielu zastosowań modelu zabezpieczeń programowych. Aplikacja może korzystać z informacji zwracanych w metodach getUserPrincipal, isUserInRole oraz getRemoteUser w dowolnej kolejności, która ma znaczenie dla tej aplikacji. Zawsze gdy jest to możliwe, należy używać modelu zabezpieczeń deklaratywnych.
public class HelloServlet extends javax.servlet.http.HttpServlet {
public void doPost(
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws javax.servlet.ServletException, java.io.IOException {
}
public void doGet(
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws javax.servlet.ServletException, java.io.IOException {
String s = "Hello";
// get remote user using getUserPrincipal()
java.security.Principal principal = request.getUserPrincipal();
String remoteUserName = "";
if( principal != null )
remoteUserName = principal.getName();
// get remote user using getRemoteUser()
String remoteUser = request.getRemoteUser();
// check if remote user is granted Mgr role
boolean isMgr = request.isUserInRole("Mgr");
// display Hello username for managers and bob.
if ( isMgr || remoteUserName.equals("bob") )
s = "Hello " + remoteUserName;
String message = "<html> \n" +
"<head><title>Hello Servlet</title></head>\n" +
"<body> /n +"
"<h1> " +s+ </h1>/n " +
byte[] bytes = message.getBytes();
// displays "Hello" for ordinary users
// and displays "Hello username" for managers and "bob".
response.getOutputStream().write(bytes);
}
}<security-role-ref>
<description> </description>
<role-name>Mgr</role-name>
</security-role-ref>