[
https://issues.apache.org/jira/browse/CXF-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730563#comment-14730563
]
Sergey Beryozkin edited comment on CXF-6573 at 9/4/15 9:38 AM:
---------------------------------------------------------------
Sure, I thought you had a standalone OAuth2 container/server on a separate
port, something we demo too, and which would likely require a SSO solution
(SAML SSO or OIDC RP - we have some decent support for these though some tuning
may be needed for the latter) - unless you do not rely on the authorization
grant but only on the grants that require no human user signing in.
If you have OAuth2 services collocated with the application services then it
can still be better to have a dedicated jaxrs:endpoint specifically for OAuth2
AccessTokenService - in which case OAuthJsonProvider will just be a single
provider. It is def faster because it is not using the reflection - though the
saving is probably 1ms given that the token responses are very small, unless
the encryption is involved... If you use a single Application (no Spring, etc)
- then yes you can't have multiple endpoints created so I see why you may need
to have both providers on a single endpoint (but note a single CXF JAXRS
servlet can be initialized with multiple Applications should you need it, or
may be you can have multiple servlets).
When you have OAuthJsonProvider and Jackson on a single endpoint and
ClientAccessToken - both providers return true from isWriteable, both providers
are typed by Object, but OAuthJsonProvider is more specific with its
Produces(application/json) as opposed to a wildcard value in Jackson - hence
OAuthJsonProvider wins. It is in the spec in the section on selecting MBW. I
have to admit this is not 100% robust - should Jackson (or other provider) also
have Produces(application/json) then we'd have 2 absolutely equal candidates on
a single endpoint and the selection process will not be unpredictable - if it
will happen in the future then we can just introduce typed OAuthJsonProvider,
example, OAuthJsonProvider<ClientAccessToken> - this will win.
I'm actually still thinking of experimenting with JAXB annotations and have a
test with a CXF Jettison based provider - we can configure it to drop
'parameters' with a stax transformation feature. Will also document about
OAuthJsonProvider asap
was (Author: sergey_beryozkin):
Sure, I thought you had a standalone OAuth2 container/server on a separate
port, something we demo too, and which would likely require a SSO solution
(SAML SSO or OIDC RP - we have some decent support for these though some tuning
may be needed for the latter) - unless you do not rely on the authorization
grant but only on the grants that require no human user signing in.
If you have OAuth2 services collocated with the application services then it
can still be better to have a dedicated jaxrs:endpoint specifically for OAuth2
AccessTokenService - in which case OAuthJsonProvider will just be a single
provider. It is def faster because it is not using the reflection - though the
saving is probably 1ms given that the token response are very small, unless the
encryption is involved... If you use a single Application (no Spring, etc) -
then yes you can't have multiple endpoints created so I see why you may need to
have both providers on a single endpoint (but note a single CXF JAXRS servlet
can be initialized with multiple Applications should you need it, or may have
have multiple servlets).
When you have OAuthJsonProvider and Jackson on a single endpoint and
ClientAccessToken - both providers return true from isWriteable, both providers
are typed by Object, but OAuthJsonProvider is more specific with its
Produces(application/json) as opposed to a wildcard value in Jackson - hence
OAuthJsonProvider wins. It is in the spec in the section on selecting MBW. I
have to admit this is not 100% robust - should Jackson (or other provider) also
have Produces(application/json) then we'd have 2 absolutely equal candidates on
a single endpoint and the selection process will not be predictable - if it
will happen in the future then we can just introduce typed OAuthJsonProvider,
example, OAuthJsonProvider<ClientAccessToken> - this will win.
I'm actually still thinking of experimenting with JAXB annotations and have a
test with a CXF Jettison based provider - we can configure it to drop
'parameters' with a stax transformation feature. Will also document about
OAuthJsonProvider asap
> AccessToken doesn't serialize with snake-case
> ---------------------------------------------
>
> Key: CXF-6573
> URL: https://issues.apache.org/jira/browse/CXF-6573
> Project: CXF
> Issue Type: Wish
> Components: JAX-RS Security
> Affects Versions: 3.1.2
> Reporter: Karl von Randow
> Priority: Minor
>
> The org.apache.cxf.rs.security.oauth2.common.AccessToken class doesn't
> declare and JAXB (or other) annotations to influence how it is serialized. So
> it uses the default serialization style of the JAXB context.
> In my case this is camel case.
> This means that the AccessToken response from the AccessTokenService uses
> camel case. The OAuth docs _appear_ (I'm not a scholar of them) to indicate
> that it should be snake case.
> Is that true? Is this a thing? Would it be something you'd consider, adding
> `@XmlElement(name = "token_key")` annotations? That would be a breaking
> change for existing users...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
