Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The fundamental problem with your scheme is that you're not using a standard framework, or implementation. This is regardless of any particular merits of your scheme itself.</p> <p>The reason is simple, security (cryptography in particular) is very, very complicated and pretty much impossible to get right. Use a common tool that is robust, well understood and proven.</p> <p>See: <strong><a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss" rel="nofollow noreferrer">http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss</a></strong> for more information on WS-Security.</p> <p>Most frameworks (.NET/JavaEE etc) will have in-built support (to some degree) for WS-Security.</p> <p>If you beleive your scheme to be better in some way than the standards, I suggest you write it up as a paper and submit it for peer-review (along with a reference implementation), but DO NOT use it to secure an application.</p> <p>EDIT to respond to OP Edit: I think you're confusing the roles of Authentication and Authorization a little, which is easy to do...</p> <p>The roll of the Security Token (or similar) in schemes is to Authenticate the sender of the message - basically, is the sender who they should be. As you rightly pointed out, Authentication does not imply anything about which underlying resources the sender is to be granted access to.</p> <p>Authorization is the process whereby you take an authenticated sender and apply some set of permissions so that you can restrict scope of access. Generally the frameworks won't do authorization by default, you either have to enable it by creating some form of ACL, or by extending some kind of "Security Manager" type interface.</p> <p>In effect, the idea is that the Authentication layer tells you who is trying to access Page A, and leaves it up to you to decide if that person is authorized to access Page A.</p> <p>You should never store information about the rights and permissions in the message itself - the receiver should verify rights against its ACL (or database or whatever) for each message. This limits your exposure should someone figure out how to modify the message.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload