我在Glassfish上使用JAX-RS来实现一组资源,只能由特定用户访问。
考虑两个用户,userA和userB,都在我的网站上注册。
http://{localhost}/service/user/A
; http://{localhost}/service/user/B
; 然后Glassfish的默认安全实现配置为:
/services/user/*
因此,登录后,userA和userB都可以访问/service/user/A
和/service/user/B
。
现在问题, 是否可能
/services/user/A
,但不能访问/services/user/B
并且同时
/services/user/B, but not
/ services / user / A` 我想我一定错过了什么,因为这是我相信的共同需求。 有人可以帮忙吗?
答案 0 :(得分:2)
这是您必须在应用程序级别实现的。应用程序服务器无法知道您的安全策略,这可能非常复杂。您可以自己完成(在用户资源中添加逻辑),如果您的安全策略很简单,这可能是正确的方法。否则,您应该查看可以与JAX-RS集成的Spring Security。这将为您提供很大的灵活性。
答案 1 :(得分:0)
在搜索之后,使用JAX-RS和JAAS解决上述问题似乎并非易事。
所以我决定看看 OAuth ,看看是否可以轻松处理授权。
经过几个小时的阅读,我开始意识到奥利维尔正在谈论的内容。我想要的是将用户身份绑定到URI。但JAAS或OAuth真的旨在解决其他问题。
JAAS 或基于角色的身份验证系统旨在授权一组用户访问一组URI。它就像一个装满玩具的房间,一旦用户扮演室友角色,这个用户就拥有房间的钥匙,然后他可以玩房间里的每一个玩具甚至毁掉所有玩具。如果你想用一个用户的名字标记每个玩具并阻止他们玩其他人的玩具,你需要在JAAS之外实现逻辑。
OAuth ,更糟糕的是。它甚至与用户和URI之间的绑定无关。它致力于让第三方代客软件使用有限访问权限的数据。考虑一下关于JAAS的房间玩具故事,你想要打开房间里的窗户,但你没有时间做这件事。所以你雇了一个男仆,并给他一个代客钥匙,让他进入房间,打开窗户,同时远离玩具。关于OAuth的神奇之处在于,代客可以获得足够的资源来完成主人的任务,更重要的是,房间知道谁通过识别代客钥匙来派代客。
现在从开发人员的角度来看,你可能会问为什么服务员可以进入窗户而不是玩具;换句话说,如何让第三方软件访问某些URI但不访问其他URI?这不是由OAuth处理的。 OAuth只告诉你哦,这是鲍勃的代客,而对于其他一切,你都是靠自己。
关于OAuth并不是一件坏事,它让你有机会决定这个代客有什么角色,或者这种代客可以访问哪些URI,或者Bob可以访问哪些资源等等。
希望这可以帮助任何阅读节省一些时间。请不要因为这个糟糕的故事而责备我,我挣扎了1个小时让故事更简单。 :)