Category Archives: PAML tokens

Token-in-token, Agent-Principal model of authorization delegation

1 Reply

PAML tokens create portable authorization where the Enforcement point need not know either the Principal making the request or the Owner authorized to grant the request. But the Principal/user must be in direct contact with the enforcement point to establish, through a cryptographic handshake, ownership of the PAML token being used. In many scenarios this direct connection is undesirable, even impossible. The Principal can not have a direct connection to the enforcement point.
A medical records repository is a good example. Security rules prohibit direct access over the internet to such a repository. Intermediary entities, application servers, firewall and the like, are mandated gateways.
In effect someone or something, must act on behalf of the Principal with the Enforcement point: An Agent.

This can be effected by placing one PAML token inside another. This token-in-token functionality is described in detail below. Any number of tokens can be embedded inside one another. In some ways like a certificate chain.
As with a standard Agent-Principal model the Principal trusts the Agent to act in the way the Principal desires. But with PAML token the Principal can narrow the Agents latitude to the extent desired.

Definition of terms

The Principal. This is the person, or entity, on whose behalf the request is undertaken.

Agent. The person or entity carrying out the request task on behalf of the Principal.

Owner. The person or entity that decides if the Principal is entitled to have the request(s) undertaken.

Enforcer. Person or entity in control of the resource and handles the request from the Agent. The Enforcer accepts the PAML token for authorization decisions.

Here is a schematic of the flow

alt text

Agent-Principal use of PAML tokens

 

Explanation of steps
Step 1 Principal prepares a list of request, or logical super-set of requests, in an XML format document; and signs this list with the Principal’s own private key. The logical super-sets can include rules according to which the requests made by the agent should be evaluated. The Agent can only carry out request on this list or ones contained in super-sets on this list. The XML document can include XSLT operations to be applied at enforcement time to the request made by the Agent. With this XSLT the Principal can enforce additional limitations (such as timing or checking token revocation list) on the requests the Agent is making.

Creating (pseudo XML document)

<principal.signature><request.list/></principal.signature>

Using the private key used to sign the request list document and the public key that belong to it: engage in cryptographic handshake with Agent and through this, establish to the Agent’s satisfaction that the Principal is in possession of the private key used to sign the request list.
Pass the signed list to the Agent.

Step 2 Agent attaches own usage conditions to Principal’s signed request.

Creating

<principal.signature><request.list/></principal.signature><agents.usage.conditions/>

And sign with the Agent’s own private key.
Creating

<agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature>

Using the private key used to sign the document and the public key that belong to it: engage in cryptographic handshake with the Owner and through this, establish to the Owner’s satisfaction that the Agent is in possession of the private key used to sign the document.
Pass the signed document to the Owner.

Step 3
Owner attaches own usage conditions to Agent’s signed request.

Creating

<agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature><owners.usage.conditions/>

And sign with the Owners own private key. This is the same private key used to sign the resource the PAML token governs access to.

Creating

<owner.signature><agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature><owners.usage.conditions/></owner.signature>

The PAML token is now completed.
Return the PAML to the Agent.

Step 4
The Agent now has a PAML token providing authorized access to resources signed with the same private key that signed the token. The PAML token can be reused to the limits specified in the owner’s usage conditions. Typically these would at least include validity time periods.
The Agent can now make request to the Enforcer and have them be authorized by the token. The requests are on behalf of the Principal but do not have to be directly from the Principal.

The Agent engages in a cryptographic handshake with the Enforcer using the private key used to sign the document from the Principal and the public key that belong to it: engage in cryptographic handshake with the Enforcer and through this, establish to the Enforcer’s satisfaction that the Agent is in possession of the private key used to create agent signature in the PAML token document.
Passed one or more PAML tokens to the Enforcer.
Pass a request to the Enforcer.

Step 5

The Enforcer examines the PAML tokens it has received. The tokens are checked in the following way and order:
XML validation. Those containing invalid XML are discarded.
XML schema validation. Those containing improper XML are discarded.
Agents signature validation: Using the public key of the Agent established in the cryptographic handshake the agent signature in the token validated. Tokens failing this validation are discarded.
Remaining tokens are tokens the Agent is properly entitled to use.

Examine the request and match it to the request list part of the remaining PAML tokens.
Those token that do not govern the request are discarded. Meaning that the request list in the token(s) do(es) not have at least one match for the request.
The remaining PAML tokens, if any, both belong to the Agent and govern the request the Agent is making.
The Enforcer examines the resource the request is for and what, if any digital signature it bears. Only if the resource bears a signature that can be validated with the same public key that can also validate the owners signature on the PAML token, is the resource considered “in scope” for the request. These two signature validation are carried out using the public key of the owner included with owner’s signature on the PAML token. If both signatures can be successfully validated the request is authorized.

In step 5 we get the desired situation that a completely stand-alone enforcement point can make authorization decisions for agents acting on behalf of someone else, without having to know the identity of either of the parties. This gives obvious benefits in reduced complexity and  ease of deployment.

sailing the data ocean

Leave a reply

What if there was a way for access to data could be authorized everywhere. If you were authorized to access a piece of data you could get access to it wherever it happened to be located.

This is not the way things work at the moment for sure, but if it could be made to work in a convenient way, what should it be like ?

When the first web browser arose some 20+ years ago. Static html pages and other media and document files where available by calling a URL over the HTTP protocol. Security was added – at first pretty coarse grained: If you were logged in you could access pretty much anything. It got better.
Comprehensive tools became available to centrally manage all web access to any document, with the finest granularity. The writing of the rules of who should access to do what, when and where, could be delegated out to those who actually were in a position to know.
But crucially, these tools could only manage access to stuff directly under their control. Often operating in a reverse-proxy mode intercepting HTTP traffic. APIs were available through which other applications could tap into them to take advantage of access control rules contained in them, to do their own authorization. In this way the data under the control of a unified set of access control rules could be made corporate wide. Access to all of a data in a corporation being governed by rules maintained in one place. Everyone would play together in the same data security pool.
In practice this never happened. (re-)Writing applications to take advantage of the API of the chosen security software platform , was too expensive. Other tools emerged to export the security rules from one software platform to another, leaving them to do their own enforcement through their own rule infrastructures. This didn’t work very well because it was too complicated. Rules are fundamentally about meaning, and meaning doesn’t translate easily. Never the less this was an attempt to federate authorization.

Data protected by the same access control rule infrastructure is part of the same pool. A database is a single pool. It has its own internal security governing access to individual pieces of data contained in it, but has no reach outside. The database maintains it’s own list of who gets to access which column in what tables.
A server has it’s own internal arrangement for governing access to the data in its own file systems. It may also have access remote file systems. Some remote file systems would be on other servers, which would govern access (NFS, FTP, Samba etc.) and would therefore not be part of the server’s own pool.

If authorizations could be federated between pools all data would exist in one big virtual pool.
A virtual pool made of multiple physical pools; individual databases, file servers etc. At present this is difficult as there may be user federation between some data pools, but each pool has it’s one authorization, it’s own way to enforce access rules. The rules in one are not known, or directly enforceable in another. There is no federated authorization.

Lets further suppose that any piece of data in this virtual data pool, data ocean really, is accessible over TCP with a URI. The URI may have various formats depending on what type of physical pool is being addressed.
For example, this would be the syntax of an URI accessing a directory (LDAP) store

ldap[s]://hostname:port/base_dn?attributes?scope?filter

And this to access a individual file, using HTTP(S)

https://host:port/path

Access to one of the secure web reverse-proxies mention above, would look like this too.

The would be many others. Note that the username and password does not appear. There would not be any prompting for this information either.
Access control would be through PAML tokens, passed in the headers. A SSL handshake would take place to establish the requesting entity’s authorization for the tokens presented.
All physical pools are defined by the entity that control access to it, and all of these entities, be they LDAP server and file/web server in the URI examples above must be equipped to handle PAML tokens to verify the authorization for the request. Through the acceptance of these PAML token the pools together form a virtual data ocean. Any application can call on data anywhere else and present PAML tokens for authorization.

This leave quite a bit of scope for application architecture. The use of a PAML token require access to the private key of the user to which the PAML token was issued. Which means that if a user is engaged in a transaction with an application and this application needs access to data kept somewhere else on behalf of the user, the application can only present its own PAML token, not forward those it has received from the users. The user must at a minimum contact this other data store directly and engage in a SSL handshake. This way the user’s ownership of the public key is established for the benefit of the data store. The application can then pass the PAML token received from the user on to the data store and the store would now know that the PAML tokens are OK to use; or the user could make the data retrieval directly and pass the data to the application that needs it. Sort of like a data federation.

Note that PAML token are tied to data, not any particular host environment. Among other things this means that the requesting client may send the server a considerable number of tokens in order to establish authorization for all required data. The server will grant the union of all these tokens.

accepting PAML tokens

Leave a reply

PAML tokens where developed to address the needs of a distributed environment. Providing the ability to make decisions at data access enforcement points without having to contact other parties.
This sounds dandy, but how exactly is it done ?

The high-level process is simple enough.

The devil is luring in the usual place.

The detail here is the digital signature on the resource item in question.
Any data item can be digitally signed, but it the data item is small the signature can be larger than the original data. There is scope for optimization here.
In the PAML token sample the digital signatures are the larger part of the total data. The balance will not be so skewed in more typical examples. But the fact remains that the digital signature in XML documents is very verbose.
This need not be the case where user data is being stored. Assuming the data item is database column with metadata, timestamps and such tings in the other columns. Additional columns can be added to contain only the relevant bits about the signature: Algorithm, Digest, Signature value. This would not take up nearly as much space and would be manageable. For optimization it would be helpful to also store the owners public key (not certificate). This would speed up processioning. When a user’s PAML Token has been accepted and the user’s request has been determined to be permitted by the token, the owners public key is known from the token. This key can be used as a mask on the data, added to SQL statements to further narrow the search in the database and exclude all rows containing data not governed by the PAML token. The user’s request is then applied to the remaining.

PAML token – sample structure

Leave a reply

PAML token

<?xml version="1.0"?>
<PAMLToken>
  <requests>
    <request URI="http://localhost:8080/.*" />
    <request URI="http://www.any14.com/.*" />
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
          Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>U67112iFgpYEazS40Oq8oI8BJZM=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>JSeXEmGoPtNTt5IzDVHPWQw4w6tM1kYHfb2cIabXoVebKFJp2RHAfYzH/LZYuLQYL+PkdJS4CPtfPFf38ndsiVmjcqD8YJL6/1zjhDYunpnIjKoy92BOvUgEOYIGhXdiqSWtlFy5HaIDsG5FTWzxQzL+kQpclgpnoSNo26oi5Tk=
      </SignatureValue>
      <KeyInfo>
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              vvBtce4rZ5xxpTdJKHa3ihe3H3vDVoh5PI/7Qw+PcuJvo7AG6VIdEx49jlk7UIWsrMFFBu01uMuKrzjXb983yDoM+0+WngR0Al2/CpOeH3xSQvjWIgcMAkfRYcSc8tgF3ycHkBV82CTIfos+1i3m365loq7ByeGT7T+EhFuEEVk=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
      </KeyInfo>
    </Signature>
  </requests>
  <Conditions NotOnOrAfter="2108-12-01T03:08:59.000Z"
    NotBefore="2008-01-03T05:00:00.000Z" />
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod
        Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>blwGeM5yJYC32cuqFBaaJ5Ha/X0=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>mkqSc/jVXh9UVCjaV1nDAnUUZNVR/pJJc8QA6IGZw7mtpBiojG0NAYe5zgLMd9RapI9eJTFDdBtZMh2eCVUySUakTFwx4h8NZXttl0v7D+lZ78Sx2mPSTYTD2gXHL4YBvyNoisHmqBSkx4ukkLhJlCP6J30XSvmHutliYUrk5Uo=
    </SignatureValue>

    <KeyInfo>
      <KeyValue>
        <RSAKeyValue>
          <Modulus>
            vvBtce4rZ5xxpTdJKHa3ihe3H3vDVoh5PI/7Qw+PcuJvo7AG6VIdEx49jlk7UIWsrMFFBu01uMuKrzjXb983yDoM+0+WngR0Al2/CpOeH3xSQvjWIgcMAkfRYcSc8tgF3ycHkBV82CTIfos+1i3m365loq7ByeGT7T+EhFuEEVk=
          </Modulus>
          <Exponent>AQAB</Exponent>
        </RSAKeyValue>
      </KeyValue>
    </KeyInfo>
  </Signature>
</PAMLToken>

Portable Authorization Management Language

Leave a reply

This is to follow up on something I wrote earlier about anonymous authorization with tokens.

The token would be in XML structure and be digitally signed. Very similar to SAML tokens in some ways.

The tokens are linked to the resource they grant access to and the user authorized to used them, with two digital signatures, one “on top of” the other. Where the one on top is created by the private key that also signed the resource the token grants access to, and the other one is by the authorized users own private key.

access token exchange process

So much for how the token can be reliably be established as authentic and authoritative.

But what about linking to the request itself. The token is passed along with the request. In the HTTP headers in most cases. The cryptographic handshake established the users authority t use the token. And the user may pass along any number of token along with the request.

But the recipient must also be able to establish that the token(s) govern(s) the request at hand not just that the user is authorized to use it(them)

Inside the token will be more XML and it will follow the conventions of the proposed Portable Authorization Management Language, PAML. These kinds of tokens are therefore named PAML tokens.

portable anonymous authorization tokens

Leave a reply

Is this a contradiction in terms? A token with which you can gain authorized access to data resource without giving your identity ? It sounds a bit fanciful to say the least. And even if it didn’t why would we even want it ?
I suggest that it is not, and that we do; and I’d like to propose, design and develop a technology that makes it possible.

First things first, what precisely do I mean by these terms.

Portable: The user can use the exact same token multiple places. Further, the access control enforcement entity need make no call to an external access control policy store in order to make a decision based on the token.

Anonymous: The token contains no personal information about the user, and the entity receiving the token, using it to establish that the user is indeed authorized to access the resource in question, can not establish the user’s identity with the token. Nor is the users identity needed in order to perform the authorization. Proper ownership of the token is established through PKI and cryptographic handshakes.

Authorization: the token is for authorization only, no authentication. If for granting access to resources the user’s identity is required, it must be established some other way.

Token: it is a piece of data. text or binary, XML or plain text. Opaque or not. Mostly passed in the HTTP headers between client and server in the client-server web model. But other ways should be just as workable, Smart cards for example. Headers have limited size, so HTTP POST must be available. In my proposal I’ll stick with XML as the format of the token. SAML tokens are passed in headers now; this token can be passed in the same way.

A fundamental question is whether or not anonymous authorization is even desirable. How can you maintain authorizations without having a database of your users in order to keep track of who you gave the access to.

And if you have a database of all your users and all the access they have, why not authenticate them and check the database for what access they should have and grant or deny their requests accordingly. No need to have special access tokens. This is how things are done now.

I suggest that this is not very efficient for ultra-large scale or distributed solutions. Every single request to be looked up against a database of access control lists. Granted, those ACL databases can themselves be cloned and distributed out to all access control enforcement points. And this is done. Excellent performance is achievable. At the expense of a complex and elaborate setup.

But it requires all these access enforcement points to be in contact with a central system to get fresh copies of the ACL database. And what about portability ? Will the enforcement point accept ACL databases from multiple sources. This may not make much sense if there data is in one place; Just have the one policy creation point and one user store. But if the data is in multiple locations ? As in a distributed system. Will all of these enforcement points authenticate the user against the same user store and authorize the requests against the same policy store? If you have enough copies of both it can be made to scale, but it is hardly efficient. User federation does not help.

With a truly portable token the enforcement point need make no reference to any other access control policy source to be able authorize or reject the request. There is then no need for high performance user stores and distributed access control policies. This significant. There are far more authorization operations than there are authentication operations. An arrangement where the two are not linked is more robust and scaleable. True, a user should only be authenticated once per session, but that still requires a user store to be available. Even with federation. So a token that can be used without a user database is to be preferred from a performance point of view.

 

NB. This is purely technical examination of these issues. From a business point of view things are quite different: The users identity is a valuable commodity that should be gathered up as much as possible along with whatever action the user takes. The legal aspect is neutral: the user’s request is properly authorized either way.

Here is a high-level view of REST-ful use of a data access token.

Portable access token

portable access token outline of usage.

 

1 User request a token from the data owner. The token can bundle multiple different requests to access data belonging to the owner.

2 Owner grants the token request after approving all the token grants access to. Sending the finished token back to the user.

Note: It makes no difference which party initiates the process of creating the token. At the end both parties have agreed what request are granted by the token, and that is enough. The owner will always have the last word, and can add limitations such as timing without input from the user, but then the user can always decline to use the token.

later

3. send token along with request.

4. check token and check user’s request against the token.

The enforcement point make no reference against a user database or rules database and therefore the token need contain no information directly identifying the user. The token can not be truly anonymous since the user must be able to establish that the user is proper user of the token, but this will not be in the form of a username.