[JBoss JIRA] (WFLY-7540) Not possible to lookup exported JMS resources by full JNDI name with java:jboss/exported/... prefix
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-7540?page=com.atlassian.jira.plugin.... ]
Miroslav Novak reassigned WFLY-7540:
------------------------------------
Assignee: David Lloyd (was: Jeff Mesnil)
> Not possible to lookup exported JMS resources by full JNDI name with java:jboss/exported/... prefix
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7540
> URL: https://issues.jboss.org/browse/WFLY-7540
> Project: WildFly
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Miroslav Novak
> Assignee: David Lloyd
>
> If exported queue/topic or connection factory is looked up from JNDI by remote client then client must use relative JNDI name.
> For example if queue is registrered in JNDI under name {{java:jboss/exported/jms/queue/InQueue}} then client must lookup {{jms/queue/InQueue}}
> In case client tries to lookup queue by full JNDI name {{java:jboss/exported/jms/queue/InQueue}} then lookup fails with exception: {code}
> javax.naming.NameNotFoundException: jboss/exported/jms/queue/InQueue -- service jboss.naming.context.java.jboss.exported.jboss.exported.jms.queue.InQueue
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) ~[na:na]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) ~[na:na]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) ~[na:na]
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127) ~[jboss-remote-naming-2.0.4.Final.jar:2.0.4.Final]
> at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73) ~[jboss-remote-naming-2.0.4.Final.jar:2.0.4.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7540) Not possible to lookup exported JMS resources by full JNDI name with java:jboss/exported/... prefix
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-7540?page=com.atlassian.jira.plugin.... ]
Miroslav Novak moved JBEAP-5558 to WFLY-7540:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7540 (was: JBEAP-5558)
Issue Type: Enhancement (was: Bug)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Remoting
(was: JMS)
(was: Remoting)
Target Release: (was: 7.1.0.GA)
Affects Version/s: 10.1.0.Final
(was: 7.0.0.GA)
(was: 7.1.0.DR2)
> Not possible to lookup exported JMS resources by full JNDI name with java:jboss/exported/... prefix
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7540
> URL: https://issues.jboss.org/browse/WFLY-7540
> Project: WildFly
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> If exported queue/topic or connection factory is looked up from JNDI by remote client then client must use relative JNDI name.
> For example if queue is registrered in JNDI under name {{java:jboss/exported/jms/queue/InQueue}} then client must lookup {{jms/queue/InQueue}}
> In case client tries to lookup queue by full JNDI name {{java:jboss/exported/jms/queue/InQueue}} then lookup fails with exception: {code}
> javax.naming.NameNotFoundException: jboss/exported/jms/queue/InQueue -- service jboss.naming.context.java.jboss.exported.jboss.exported.jms.queue.InQueue
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) ~[na:na]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) ~[na:na]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) ~[na:na]
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127) ~[jboss-remote-naming-2.0.4.Final.jar:2.0.4.Final]
> at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73) ~[jboss-remote-naming-2.0.4.Final.jar:2.0.4.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7176) Review x500-attribute-principal-decoder resource in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7176?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7176 at 11/9/16 7:59 AM:
-----------------------------------------------------------
I think the only thing to consider is allowing of segments definition by name (like "cn"), instead of OID.
[~dlofthouse], do we want it? Or can I set x500-attribute-principal-decoder as stable?
was (Author: honza889):
I think the only thing to consider is allowing of segments definition by name, instead of OID.
[~dlofthouse], do we want it? Or can I set x500-attribute-principal-decoder as stable?
> Review x500-attribute-principal-decoder resource in Elytron subsystem
> ---------------------------------------------------------------------
>
> Key: WFLY-7176
> URL: https://issues.jboss.org/browse/WFLY-7176
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> See description of JBEAP-6100 for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-7235?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reopened WFLY-7235:
------------------------------
Apparently changes in clustering triggered this issue again.
> InfinispanResourceRefTestCase fails with security manager
> ---------------------------------------------------------
>
> Key: WFLY-7235
> URL: https://issues.jboss.org/browse/WFLY-7235
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
> Fix For: 11.0.0.Alpha1
>
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
> at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> ... 210 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-7235?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-7235:
-----------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9254, https://github.com/wildfly/wildfly/pull/9366 (was: https://github.com/wildfly/wildfly/pull/9254)
> InfinispanResourceRefTestCase fails with security manager
> ---------------------------------------------------------
>
> Key: WFLY-7235
> URL: https://issues.jboss.org/browse/WFLY-7235
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
> Fix For: 11.0.0.Alpha1
>
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
> at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> ... 210 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2127) UnicastHeader3: reduce in-memory size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2127?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2127:
---------------------------
Description:
JOL reports:
{noformat}
org.jgroups.protocols.UnicastHeader3 object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
12 2 short Header.prot_id 0
14 2 (alignment/padding gap) N/A
16 8 long UnicastHeader3.seqno 0
24 8 long UnicastHeader3.timestamp 0
32 2 short UnicastHeader3.conn_id 0
34 1 byte UnicastHeader3.type 0
35 1 boolean UnicastHeader3.first false
36 4 (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 2 bytes internal + 4 bytes external = 6 bytes total
{noformat}
We could reduce the size to 32 by making {{timestamp}} an int. This field is used for comparison against previous timestamps, and since the comparison takes numeric overflow into account, wrap-around is not a problem.
After the change of {{timestamp}} from {{long}} -> {{int}}:
{noformat}
org.jgroups.protocols.UnicastHeader3 object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
12 2 short Header.prot_id 0
14 2 (alignment/padding gap) N/A
16 8 long UnicastHeader3.seqno 0
24 4 int UnicastHeader3.timestamp 0
28 2 short UnicastHeader3.conn_id 0
30 1 byte UnicastHeader3.type 0
31 1 boolean UnicastHeader3.first false
Instance size: 32 bytes
Space losses: 2 bytes internal + 0 bytes external = 2 bytes total
{noformat}
was:
JOL reports:
{noformat}
org.jgroups.protocols.UnicastHeader3 object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
12 2 short Header.prot_id 0
14 2 (alignment/padding gap) N/A
16 8 long UnicastHeader3.seqno 0
24 8 long UnicastHeader3.timestamp 0
32 2 short UnicastHeader3.conn_id 0
34 1 byte UnicastHeader3.type 0
35 1 boolean UnicastHeader3.first false
36 4 (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 2 bytes internal + 4 bytes external = 6 bytes total
{noformat}
We could reduce the size to 32 by making {{timestamp}} an int. This field is used for comparison against previous timestamps, and since the comparison takes numeric overflow into account, wrap-around is not a problem.
> UnicastHeader3: reduce in-memory size
> -------------------------------------
>
> Key: JGRP-2127
> URL: https://issues.jboss.org/browse/JGRP-2127
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> JOL reports:
> {noformat}
> org.jgroups.protocols.UnicastHeader3 object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
> 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
> 8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
> 12 2 short Header.prot_id 0
> 14 2 (alignment/padding gap) N/A
> 16 8 long UnicastHeader3.seqno 0
> 24 8 long UnicastHeader3.timestamp 0
> 32 2 short UnicastHeader3.conn_id 0
> 34 1 byte UnicastHeader3.type 0
> 35 1 boolean UnicastHeader3.first false
> 36 4 (loss due to the next object alignment)
> Instance size: 40 bytes
> Space losses: 2 bytes internal + 4 bytes external = 6 bytes total
> {noformat}
> We could reduce the size to 32 by making {{timestamp}} an int. This field is used for comparison against previous timestamps, and since the comparison takes numeric overflow into account, wrap-around is not a problem.
> After the change of {{timestamp}} from {{long}} -> {{int}}:
> {noformat}
> org.jgroups.protocols.UnicastHeader3 object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
> 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
> 8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
> 12 2 short Header.prot_id 0
> 14 2 (alignment/padding gap) N/A
> 16 8 long UnicastHeader3.seqno 0
> 24 4 int UnicastHeader3.timestamp 0
> 28 2 short UnicastHeader3.conn_id 0
> 30 1 byte UnicastHeader3.type 0
> 31 1 boolean UnicastHeader3.first false
> Instance size: 32 bytes
> Space losses: 2 bytes internal + 0 bytes external = 2 bytes total
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JGRP-2127) UnicastHeader3: reduce in-memory size
by Bela Ban (JIRA)
Bela Ban created JGRP-2127:
------------------------------
Summary: UnicastHeader3: reduce in-memory size
Key: JGRP-2127
URL: https://issues.jboss.org/browse/JGRP-2127
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 4.0
JOL reports:
{noformat}
org.jgroups.protocols.UnicastHeader3 object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 9d 11 01 f8 (10011101 00010001 00000001 11111000) (-134147683)
12 2 short Header.prot_id 0
14 2 (alignment/padding gap) N/A
16 8 long UnicastHeader3.seqno 0
24 8 long UnicastHeader3.timestamp 0
32 2 short UnicastHeader3.conn_id 0
34 1 byte UnicastHeader3.type 0
35 1 boolean UnicastHeader3.first false
36 4 (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 2 bytes internal + 4 bytes external = 6 bytes total
{noformat}
We could reduce the size to 32 by making {{timestamp}} an int. This field is used for comparison against previous timestamps, and since the comparison takes numeric overflow into account, wrap-around is not a problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7476) Complicated failure-descriptions in Elytron properties-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7476?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7476:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Complicated failure-descriptions in Elytron properties-realm
> ------------------------------------------------------------
>
> Key: WFLY-7476
> URL: https://issues.jboss.org/browse/WFLY-7476
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
>
> There are complicated failure-descriptions in Elytron properties-realm. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description.
> Examples of complicated failure-description in properties-realm:
> * Adding path which does not exist:
> {code}
> /subsystem=elytron/properties-realm=realm:add(users-properties={path=/wrong/path/a.properties})
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.realm: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
> Caused by: java.io.FileNotFoundException: /wrong/path/a.properties (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.realm"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> * Adding file with missing $REALM:
> {code}
> /subsystem=elytron/properties-realm=realm:add(users-properties={path=/some/path/roles.properties})
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.realm" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.realm: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
> Caused by: java.io.IOException: ELY01006: No realm name found in properties file"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.realm"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> * path mentiond in relative-to does not exist:
> {code}
> /subsystem=elytron/properties-realm=realm:add(users-properties={path=users.properties,relative-to=non.exist})
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-realm.realm is missing [jboss.server.path.\"non.exist\"]"]
> },
> "rolled-back" => true
> }
> {code}
> Suggestion for improvement:
> * use only description of failure, e.g. something like "file /wrong/path/a.properties was not found"
> * do not use any unneeded information - e.g. "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-455) OAuth2 Credential Store
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-455:
--------------------------------
OAuth2 basically translates to a special type of token that is actually used to actually access resources protected by a resource server, the *access_token*. This protocol also defines another special type of token that can be used to refresh a access_token, the *refresh_token*.
For some OAuth2 Grant Types, the refresh_token is obtained from the same response that returned the access_token. For these grant types, we need to be able to also store the refresh_token in order to be able to refresh a access_token later.
In addition to that, an Access Token Response from an Authorization Server also provides some important information about the access_token such as *expiration* time. This is probably another information that we need to have in the credential store.
>From a design perspective, I think we would need a specific credential type called {{OAuth2AccessTokenCredential}}. This type would be an extension of a {{BearerTokenCredential}} with some additional state to hold information about the access token. For instance, refresh_token and expiration, as mentioned before.
Regarding the logic to actually refresh access tokens and check their validity, we will be using a separated component such as a {{CallbackHandler}}. Which will use the OAuth2 Credential Store to store/retrieve tokens. We already have two JIRAs for these CBHs: ELY-675 and ELY-658.
Any comments ?
> OAuth2 Credential Store
> -----------------------
>
> Key: ELY-455
> URL: https://issues.jboss.org/browse/ELY-455
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Credential Store
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Fix For: 1.1.0.Beta14
>
>
> Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months