search

OAuth-Apis / apis

OAuth Authorization as a Service
Apache License 2.0
593 stars 301 forks source link

Token validation endpoint returns burdensome Java type information #15

Closed celkins closed 11 years ago

celkins commented 11 years ago

Since 3673319 the serialization of VerifyTokenResponse contains Java type information. The following is a representative example from the authorization server webapp:

["org.surfnet.oaaas.model.VerifyTokenResponse",
{
    "audience": "client",
    "scopes": ["org.apache.openjpa.util.java$util$ArrayList$proxy", ["read", "write"]],
    "principal": ["org.surfnet.oaaas.conext.SAMLAuthenticatedPrincipal",
    {
        "name": "admin",
        "roles": ["java.util.ArrayList", []],
        "groups": ["java.util.ArrayList", []],
        "adminPrincipal": false,
        "attributes": ["java.util.HashMap",
        {
            "DISPLAY_NAME": "admin",
            "IDENTITY_PROVIDER": "http://mock-idp"
        }]
    }],
    "expires_in": 0
}]

In order to deserialize such JSON, a resource server must explicitly include at least two additional dependencies (and inherit their numerous transitive dependencies). Otherwise, it will experience errors such as the following:

ERROR [2013-07-02 19:36:14,535] org.surfnet.oaaas.auth.AuthorizationServerFilter: Exception in reading result from AuthorizationServer
! org.codehaus.jackson.map.JsonMappingException: Invalid type id 'org.surfnet.oaaas.conext.SAMLAuthenticatedPrincipal' (for id type 'Id.class'): no such class found (through reference chain: org.surfnet.oaaas.model.VerifyTokenResponse["principal"])

The OpenJPA dependency, although extraneous from the resource server's perspective, can be easily handled by declaring it in apis-resource-server-library/pom.xml.

However, the SAML dependency is indicative of a larger problem, which is that the presence of this type information couples a resource server to the specific authenticators used by the authorization server. That is especially surprising when simply using AuthorizationServerFilter to protect resources.

gvanderploeg commented 11 years ago

You are absolutely right. It was always the intention that the VerifyTokenResponse be a language-agnostic structure. The dependency on the SAML package shouldn't also be there.

oharsta commented 11 years ago

Fixed in feature branch issue-15-configurable-type-information-json. I need to think about the way to integration test both the options (as the type info is now default disabled, but I still want to test end-to-end the enabled variant as some scenario's depend on this) and then I will merge the branch with master.

oharsta commented 11 years ago

Merged the issue-15-configurable-type-information-json branch into master and upped the documentation with regard to the default (not including type information in the JSON) behavior and the means to override this.