Introduction
Extended from the discussions in Authorization Service - Return list of Permissions, here is the proposed version 2.0 spec. This design aims to be fully backward-compatible with version 1.0 - Version 1.0 message is also a valid Version 2.0 message (except the version number). This can make it possible that a version 1.0 client can send a version 1.0 request, and process a version 2.0 reply without issues.
Message Definitions
Comparison of Version 2.0 versus 1.0
<!ELEMENT Authorization (Principal, Permission, TestRequest?)>
<!ATTLIST Authorization
isAuthorized CDATA #REQUIRED
>
<!ELEMENT AuthorizationQuerySpecification (Principal, Permission)>
|
<!ELEMENT Authorization (Principal, Permission*, TestRequest?)>
<!ATTLIST Authorization
isAuthorized CDATA #IMPLIED
>
<!ELEMENT AuthorizationQuerySpecification (Principal, Permission*)>
|
Example Messages
Example 1:
<AuthorizationQuerySpecification>
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
</AuthorizationQuerySpecification>
<Authorization isAuthorized="true">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
</Authorization>
|
This is the same as Version 1.0
Example 2:
<AuthorizationQuerySpecification>
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
<Permission>edu.emory.AuthorizationTestApplication2.use</Permission>
<Permission>edu.emory.AuthorizationTestApplication3.use</Permission>
</AuthorizationQuerySpecification>
<Authorization isAuthorized="true">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
<Permission>edu.emory.AuthorizationTestApplication2.use</Permission>
</Authorization>
<Authorization isAuthorized="false">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication3.use</Permission>
</Authorization>
<Authorization isAuthorized="true">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
</Authorization>
<Authorization isAuthorized="true">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication2.use</Permission>
</Authorization>
<Authorization isAuthorized="false">
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication3.use</Permission>
</Authorization>
<Authorization>
<Principal>swheat</Principal>
<Permission>edu.emory.AuthorizationTestApplication.use</Permission>
<Permission>edu.emory.AuthorizationTestApplication2.use</Permission>
</Authorization>
|
Please note that reply 1-3 are all valid response, and have the same semantics. Only 1 reply will be returned. Current implementation only return type-1 reply, though client codes which are capable of processing all 3 are trivial to implement.
Example test EPPN message and response
Message
<AuthorizationQuerySpecification>
<Principal>anid@gatech.edu</Principal>
<Permission>org.myorg.myapp.viewPage1</Permission>
<Permission>org.myorg.myapp.viewPage2</Permission>
<Permission>org.myorg.myapp.viewPage3</Permission>
</AuthorizationQuerySpecification>
|
Response
<Authorization isAuthorized="true">
<Principal>anid@gatech.edu</Principal>
<Permission>org.myorg.myapp.viewPage1</Permission>
<Permission>org.myorg.myapp.viewPage2</Permission>
</Authorization>
<Authorization isAuthorized="false">
<Principal>anid@gatech.edu</Principal>
<Permission>org.myorg.myapp.viewPage3</Permission>
</Authorization>
|