REST应用程序中的基本身份验证
Sam*_*ami 14 java html5 authorization basic-authentication http-headers
环境:
- JAVA
- Glassfish的
- 不同机器中的REST服务
- 带有AJAX和JQuery的HTML5客户端
- 新泽西
这是我到目前为止所实现的:
HTML5客户端###
$('#btnSignIn').click(function () {
var username = $("#username").val();
var password = $("#password").val();
function make_base_auth(user, password) {
var tok = user + ':' + password;
var final = "Basic " + $.base64.encode(tok);
console.log("FINAL---->" + final);
alert("FINAL---->" + final);
return final;
}
$.ajax({
type: "GET",
contentType: "application/json",
url: "http://localhost:8080/SesameService/webresources/users/secured/login",
crossDomain: true,
dataType: "text",
async: false,
data: {},
beforeSend: function (xhr) {
xhr.setRequestHeader('authorization', make_base_auth(username, password));
},
success: function () {
alert('Thanks for your signin in! ');
},
error: function (jqXHR, textStatus, errorThrown) {
console.log(textStatus, errorThrown);
alert(' Error in signIn-process!! ' + textStatus);
}
});
});
服务器
在安全性方面,我没有启用安全管理器,它被禁用!
我已经为Glassfish配置了BASIC身份验证,我的web.xml看起来像这样:
<servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/webresources/*</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>REST Protected resources</web-resource-name>
<description/>
<url-pattern>/users/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
<role-name>customer</role-name>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>jdbcRealm</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
<security-role>
<description/>
<role-name>customer</role-name>
</security-role>
GLASSFISH
LOG
FINE: [Web-Security] Setting Policy Context ID: old = null ctxID = SesameService/SesameService
FINE: [Web-Security] hasUserDataPermission perm: ("javax.security.jacc.WebUserDataPermission" "/webresources/users/secured/login" "GET")
FINE: [Web-Security] hasUserDataPermission isGranted: true
FINE: [Web-Security] Policy Context ID was: SesameService/SesameService
FINE: [Web-Security] hasResource isGranted: true
FINE: [Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/webresources/users/secured/login" "GET")
题:
如果我在用户注册并在SSL/HTTPS下传输密码时在客户端加密(NOT编码)密码,这是否是安全且良好的实现方法？
如果我在没有客户端的情况下使用REST服务,它总是打开的,为什么？没有BASIC认证？我是否理解了这些网址模式的错误？
Run Code Online (Sandbox Code Playgroud)http://localhost:8080/SesameService/webresources/users/secured/login如果我得到这个工作如何测试,因为现在如果我验证一次,我总是授权？是否可以在REST服务中以编程方式"注销",或者通常如何实现注销？
在头文件中使用强制base64编码的用户名:password时,我是否必须将我的用户名和密码编码为DB？我尝试了,并将编码(允许值为Hex和Base64)添加到jdbcRealm到Glassfish,似乎密码就足够了,但是当两者都在客户端编码时会发生什么？
更新:我改变web.xml和现在在浏览器中调用直REST的服务时BASIC认证工作:http://localhost:8080/SesameService/users/secured/login
变化:
- 我在Glassfish中启用了安全管理器
我改变了url-pattern
ServletAdaptor/*---->我关闭了webresources.它是由Netbeans生成的
我更改了网址以服务于此:
http://localhost:8080/SesameService/users/secured/login
现在,当我尝试从HTML5客户端进行身份验证时,我获得了HTTP/1.1 401 Unauthorized.
请求标题: `
Origin: http://localhost:8383
Host:`localhost:8080`
Connection:keep-alive
Access-Control-Request-Method:GET
Access-Control-Request-Headers:authorization,content-type`
响应:
x-powered-by:Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
WWW-Authenticate:Basic realm="jdbcRealm"
Server:GlassFish Server Open Source Edition 3.1.2.2
Pragma:No-cache
Expires:Thu, 01 Jan 1970 02:00:00 EET
Date:Sat, 13 Apr 2013 15:25:06 GMT
Content-Type:text/html
Content-Length:1073
Cache-Control:no-cache
更新2
当我尝试用JavaScript +授权头验证我得到401错误,并且在日志中:
FINE: [Web-Security] Setting Policy Context ID: old = null ctxID = SesameService/SesameService
FINE: [Web-Security] hasUserDataPermission perm: ("javax.security.jacc.WebUserDataPermission" "/users/secured/login" "OPTIONS")
FINE: [Web-Security] hasUserDataPermission isGranted: true---->!!!!!!!!!!!!!
FINE: [Web-Security] Policy Context ID was: SesameService/SesameService
FINE: [Web-Security] Codesource with Web URL: file:/SesameService/SesameService
FINE: [Web-Security] Checking Web Permission with Principals : null------->!!!!!!!
FINE: [Web-Security] Web Permission = ("javax.security.jacc.WebResourcePermission" "/users/secured/login" "OPTIONS")
FINEST: JACC Policy Provider: PolicyWrapper.implies, context (SesameService/SesameService)- result was(false) permission (("javax.security.jacc.WebResourcePermission" "/users/secured/login" "OPTIONS"))
FINE: [Web-Security] hasResource isGranted: false------->!!!!!!!!!
FINE: [Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/users/secured/login" "OPTIONS")
FINEST: JACC Policy Provider: PolicyWrapper.getPermissions(cs), context (null) codesource ((null <no signer certificates>)) permissions: java.security.Permissions@5d4de3b0 (
****更新3****我不能成为第一个也是唯一一个在跨域案例中尝试使用BASIC进行身份验证的人.我更改了我的交叉源过滤器:response.getHttpHeaders().putSingle("Access-Control-Allow-Headers","Authorization");
没有401错误,但JavaScript仍然出错.在Glassfish日志中:
FINEST: JACC Policy Provider:
getPolicy (SesameService/SesameService) is NOT in service----->!!!!!!!!
FINE: JACC Policy Provider: file arrival check type: granted arrived: false exists: false lastModified: 0 storedTime: 1365968416000 state: deleted SesameService/SesameService
FINE: JACC Policy Provider: file arrival check type: excluded arrived: false exists: false lastModified: 0 storedTime: 0 state: deleted SesameService/SesameService
FINE: TM: getTransaction: tx=null, tm=null
FINE: TM: componentDestroyedorg.apache.catalina.servlets.DefaultServlet@227fe9a8
FINE: TM: resourceTable before: 0
FINE: TM: resourceTable after: 0
顺便说一句,因为我从来没有得到过这项工作,所以这比在自己的域中直接调用REST服务一样.那么,第一个客户端请求,服务器请求和用户名密码窗口打开,然后客户端请求和服务器验证并响应页面？我试图得到它:请求带有Authorization标头,来自服务器的响应以及来自其余服务的结果,就是这样.知道如何保护REST服务吗？比那更容易？这是不可能的.
更新4
我只是试图将我的HTML5客户端移动到java web-project下,只是纯html页面并且在同一个域下,BASIC-authentication正在100%工作.所以原因是因为跨域环境.
如果我在用户注册并在SSL/HTTPS下传输密码时在客户端加密(NOT编码)密码,这是否是安全且良好的实现方法？
最有可能的是,您应该通过SSL/HTTPS以纯文本形式传递密码.
SSL/HTTPS中的所有通信都是加密的,因此加密密码可能不是一个好主意,除非您需要确保Web服务器(技术上是HTTPS终结器)无法看到密码.
如果我在没有客户端的情况下使用REST服务,它总是打开的,为什么？没有BASIC认证？我是否理解了这些网址模式的错误？
不确定我理解这个问题.但是,BASIC auth不是REST中用于身份验证的良好模式,因为它以纯文本形式传递密码.
如果我得到这个工作如何测试,因为现在如果我验证一次,我总是授权？是否可以在REST服务中以编程方式"注销",或者通常如何实现注销？
在Basic Auth中,客户端在每个HTTP请求中传递用户名和密码.如果客户端未传递凭据,则服务器拒绝该请求.因此,没有会话的概念.
但是,就Java EE服务器而言,登录会创建用户会话,同一用户将来的请求将使用相同的会话.如果您这样配置它,此会话将超时.
如果注销很重要(即控制用户会话),则必须为此创建一个servlet(/ logout),这会使HTTP会话无效.
标准Java安全模型的工作原理如下:当用户登录到安全领域时,Java EE服务器会在浏览器中存储安全cookie.浏览器在每个请求中将此cookie发送回Java EE服务器到同一领域.Java EE服务器在每个请求中检查此cookie,并使用它来标识用户,将请求连接到用户的会话.
因此,您可能希望在与Web应用程序相同的安全领域中使用REST服务,因此浏览器和服务器可以无缝地工作.
在头文件中使用强制base64编码的用户名:password时,我是否必须将我的用户名和密码编码为DB？我尝试了,并将编码(允许值为Hex和Base64)添加到jdbcRealm到Glassfish,似乎密码就足够了,但是当两者都在客户端编码时会发生什么？
不,不要对用户名或密码进行编码 - 这一切都在浏览器和Glassfish中深入处理.如果您在客户端编码,客户端将编码编码,服务器将拒绝密码.
你能不能告诉我是否可以使用java脚本的html5-page中的j_security_check或者我再次遇到问题:)我已经使用了FORM-auth做了几个Primefaces + jsf-application并且没有任何问题,但是这对我来说完全是灾难.
假设RESTful服务保持在同一个域和安全领域(然后登录到Web应用程序将允许浏览器将正确的cookie发送到REST URI),您应该能够使用j_security_check轻松地使用j_security_check.
但请注意,其他应用程序将无法访问REST服务.基本上,他们必须通过j_security_check登录,然后维护Glassfish发送的cookie.如果您确实需要其他应用程序以编程方式访问这些服务,那么您将需要另一个解决方案:
- 您可以设置安全领域以允许不同的身份验证器"足够"; 设置HTTP基本认证以及与确保没有被标记为"必要"
- 部署RESTful服务两次,另一次是不同的URI.如果要使用HTTP BASIC Auth,这可能是SSL/HTTPS端点,以确保安全地处理密码