9:23 a.m.
I'm looking at Undertow handlers and Auth mechanisms and trying to
figure out how to port resteasy oauth. I need to be able to do the
following
1. check a cookie to see if user is already logged in.
2. If not redirect to auth server
3. get a redirect back from auth server
4. make an HTTP request to server based on information from the request
5. Obtain a token from this request
6. Parse and validate the token to obtain user identity and role mappings
7. Propagate the identity and role mappings so other layers can do their
thing (like role checks)
I can do most of this within a AuthenticationMechanism. sendChallenge()
would be used to send the redirect to the auth server. I think a custom
IdentityManager is needed. This would accept a custom Credential. The
Credential would have the identity and role mappings within it and the
IdentityManager would allocate an Account based on this information.
So, thats for Undertow....but I don't see any way to wire this all up
for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
no way of wiring up AuthenticationMechanisms. I see no other undertow
specific config except for undertow-handlers.conf.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:24 a.m.
I have an added problem here of having to provide configuration for
this. (i.e. keys).
On 8/14/2013 8:23 PM, Bill Burke wrote:
I'm looking at Undertow handlers and Auth mechanisms and trying
to
figure out how to port resteasy oauth. I need to be able to do the
following
1. check a cookie to see if user is already logged in.
2. If not redirect to auth server
3. get a redirect back from auth server
4. make an HTTP request to server based on information from the request
5. Obtain a token from this request
6. Parse and validate the token to obtain user identity and role mappings
7. Propagate the identity and role mappings so other layers can do their
thing (like role checks)
I can do most of this within a AuthenticationMechanism. sendChallenge()
would be used to send the redirect to the auth server. I think a custom
IdentityManager is needed. This would accept a custom Credential. The
Credential would have the identity and role mappings within it and the
IdentityManager would allocate an Account based on this information.
So, thats for Undertow....but I don't see any way to wire this all up
for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
no way of wiring up AuthenticationMechanisms. I see no other undertow
specific config except for undertow-handlers.conf.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:37 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: undertow-dev(a)lists.jboss.org
Sent: Thursday, 15 August, 2013 2:24:49 AM
Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth
I have an added problem here of having to provide configuration for
this. (i.e. keys).
On 8/14/2013 8:23 PM, Bill Burke wrote:
> I'm looking at Undertow handlers and Auth mechanisms and trying to
> figure out how to port resteasy oauth. I need to be able to do the
> following
>
> 1. check a cookie to see if user is already logged in.
> 2. If not redirect to auth server
> 3. get a redirect back from auth server
> 4. make an HTTP request to server based on information from the request
> 5. Obtain a token from this request
> 6. Parse and validate the token to obtain user identity and role mappings
> 7. Propagate the identity and role mappings so other layers can do their
> thing (like role checks)
>
> I can do most of this within a AuthenticationMechanism. sendChallenge()
> would be used to send the redirect to the auth server. I think a custom
> IdentityManager is needed. This would accept a custom Credential. The
> Credential would have the identity and role mappings within it and the
> IdentityManager would allocate an Account based on this information.
I don't think you actually need a custom identity manager, your mechanism can just
create a new Account
and pass it to the SecurityContext.authenticationComplete() method.
>
> So, thats for Undertow....but I don't see any way to wire this all up
> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
> no way of wiring up AuthenticationMechanisms. I see no other undertow
> specific config except for undertow-handlers.conf.
What you can do here is provide a io.undertow.servlet.ServletExtension implementation
(with a META-INF/services entry).
This allows you to modify the deployment before boot time, so you can check for the
presence of a custom configuration file (e.g. jboss-oauth.xml or whatever),
and if it is present modify the deployment accordingly, adding your authentication
mechanism, and possibly any additional handlers etc that you need.
At some point soon we will probably provide some way of configuring additional mechanisms
declaratively in jboss-web.xml as well, but that basically limits you to just
installing a mechanism and configuring via key value properties.
The trickier problem is the JAAS Identity Manager. This was always intended to be
temporary, but I really doubt that PL IDM will be replacing JAAS so I think we might be
stuck with it.
Because this was intended to be temporary there is some additional functionality in the
IDM that does not really belong there (namely it modifies the picketbox security context,
and pushes the principal vs role map thread local). I will have a look at this today and
try and clean this up a bit.
Stuart
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
9:11 p.m.
On 8/15/2013 5:37 AM, Stuart Douglas wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Thursday, 15 August, 2013 2:24:49 AM
> Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth
>
> I have an added problem here of having to provide configuration for
> this. (i.e. keys).
>
> On 8/14/2013 8:23 PM, Bill Burke wrote:
>> I'm looking at Undertow handlers and Auth mechanisms and trying to
>> figure out how to port resteasy oauth. I need to be able to do the
>> following
>>
>> 1. check a cookie to see if user is already logged in.
>> 2. If not redirect to auth server
>> 3. get a redirect back from auth server
>> 4. make an HTTP request to server based on information from the request
>> 5. Obtain a token from this request
>> 6. Parse and validate the token to obtain user identity and role mappings
>> 7. Propagate the identity and role mappings so other layers can do their
>> thing (like role checks)
>>
>> I can do most of this within a AuthenticationMechanism. sendChallenge()
>> would be used to send the redirect to the auth server. I think a custom
>> IdentityManager is needed. This would accept a custom Credential. The
>> Credential would have the identity and role mappings within it and the
>> IdentityManager would allocate an Account based on this information.
I don't think you actually need a custom identity manager, your mechanism can just
create a new Account
and pass it to the SecurityContext.authenticationComplete() method.
CachedAuthenticatedSessionMechanism does a:
Account account =
securityContext.getIdentityManager().verify(authSession.getAccount());
So, I couldn't have a null IdentityManager, I'd at least have to have a
dummy IdentityManager. Plus, the thread local binding of the
subject/principal/role mappings is done within the Wildfly JaaS adapter.
>>
>> So, thats for Undertow....but I don't see any way to wire this all up
>> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
>> no way of wiring up AuthenticationMechanisms. I see no other undertow
>> specific config except for undertow-handlers.conf.
What you can do here is provide a io.undertow.servlet.ServletExtension implementation
(with a META-INF/services entry).
This allows you to modify the deployment before boot time, so you can check for the
presence of a custom configuration file (e.g. jboss-oauth.xml or whatever),
and if it is present modify the deployment accordingly, adding your authentication
mechanism, and possibly any additional handlers etc that you need.
Very nice.
At some point soon we will probably provide some way of configuring
additional mechanisms declaratively in jboss-web.xml as well, but that basically limits
you to just
installing a mechanism and configuring via key value properties.
I like the extension model better.
The trickier problem is the JAAS Identity Manager. This was always
intended to be temporary, but I really doubt that PL IDM will be replacing JAAS so I think
we might be stuck with it.
Because this was intended to be temporary there is some additional functionality in the
IDM that does not really belong there (namely it modifies the picketbox security context,
and pushes the principal vs role map thread local). I will have a look at this today and
try and clean this up a bit.
Can't I just call setIdentityManager within my ServletExtension? I know
the JaaS IdentityManager is already kind of hacked because verify()'s
behavior is overloaded to propagate the Subject, but its simpler than
providing another SPI.
Thanks.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:43 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Thursday, 15 August, 2013 2:11:12 PM
Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth
On 8/15/2013 5:37 AM, Stuart Douglas wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: undertow-dev(a)lists.jboss.org
>> Sent: Thursday, 15 August, 2013 2:24:49 AM
>> Subject: Re: [undertow-dev] figuring out how to integration resteasy oauth
>>
>> I have an added problem here of having to provide configuration for
>> this. (i.e. keys).
>>
>> On 8/14/2013 8:23 PM, Bill Burke wrote:
>>> I'm looking at Undertow handlers and Auth mechanisms and trying to
>>> figure out how to port resteasy oauth. I need to be able to do the
>>> following
>>>
>>> 1. check a cookie to see if user is already logged in.
>>> 2. If not redirect to auth server
>>> 3. get a redirect back from auth server
>>> 4. make an HTTP request to server based on information from the request
>>> 5. Obtain a token from this request
>>> 6. Parse and validate the token to obtain user identity and role mappings
>>> 7. Propagate the identity and role mappings so other layers can do their
>>> thing (like role checks)
>>>
>>> I can do most of this within a AuthenticationMechanism. sendChallenge()
>>> would be used to send the redirect to the auth server. I think a custom
>>> IdentityManager is needed. This would accept a custom Credential. The
>>> Credential would have the identity and role mappings within it and the
>>> IdentityManager would allocate an Account based on this information.
>
> I don't think you actually need a custom identity manager, your mechanism
> can just create a new Account
> and pass it to the SecurityContext.authenticationComplete() method.
>
CachedAuthenticatedSessionMechanism does a:
Account account =
securityContext.getIdentityManager().verify(authSession.getAccount());
So, I couldn't have a null IdentityManager, I'd at least have to have a
dummy IdentityManager. Plus, the thread local binding of the
subject/principal/role mappings is done within the Wildfly JaaS adapter.
Good point. With regard to the thread local bindings I will be moving them out of the JAAS
IDM shortly.
>>>
>>> So, thats for Undertow....but I don't see any way to wire this all up
>>> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
>>> no way of wiring up AuthenticationMechanisms. I see no other undertow
>>> specific config except for undertow-handlers.conf.
>
> What you can do here is provide a io.undertow.servlet.ServletExtension
> implementation (with a META-INF/services entry).
> This allows you to modify the deployment before boot time, so you can check
> for the presence of a custom configuration file (e.g. jboss-oauth.xml or
> whatever),
> and if it is present modify the deployment accordingly, adding your
> authentication mechanism, and possibly any additional handlers etc that
> you need.
>
Very nice.
> At some point soon we will probably provide some way of configuring
> additional mechanisms declaratively in jboss-web.xml as well, but that
> basically limits you to just
> installing a mechanism and configuring via key value properties.
>
I like the extension model better.
> The trickier problem is the JAAS Identity Manager. This was always intended
> to be temporary, but I really doubt that PL IDM will be replacing JAAS so
> I think we might be stuck with it.
> Because this was intended to be temporary there is some additional
> functionality in the IDM that does not really belong there (namely it
> modifies the picketbox security context, and pushes the principal vs role
> map thread local). I will have a look at this today and try and clean this
> up a bit.
>
Can't I just call setIdentityManager within my ServletExtension? I know
the JaaS IdentityManager is already kind of hacked because verify()'s
behavior is overloaded to propagate the Subject, but its simpler than
providing another SPI.
You can, you just have to mimic the behaviour of the JAAS IDM to some extent, in terms of
setting up the Picketbox security context. Not ideal but it will certainly work.
Stuart
Thanks.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:56 p.m.
I will put something together shortly for the mechanism overrides, I
previously proposed a solution to these lists a while back which
received quite a bit of support.
Overall mechanism overrides will either be possible using the subsystem
configuration or deployment specific configuration providing both ways
to set the mechanism for the app being deployed.
Regards,
Darran Lofthouse.
On 15/08/13 01:23, Bill Burke wrote:
I'm looking at Undertow handlers and Auth mechanisms and trying
to
figure out how to port resteasy oauth. I need to be able to do the
following
1. check a cookie to see if user is already logged in.
2. If not redirect to auth server
3. get a redirect back from auth server
4. make an HTTP request to server based on information from the request
5. Obtain a token from this request
6. Parse and validate the token to obtain user identity and role mappings
7. Propagate the identity and role mappings so other layers can do their
thing (like role checks)
I can do most of this within a AuthenticationMechanism. sendChallenge()
would be used to send the redirect to the auth server. I think a custom
IdentityManager is needed. This would accept a custom Credential. The
Credential would have the identity and role mappings within it and the
IdentityManager would allocate an Account based on this information.
So, thats for Undertow....but I don't see any way to wire this all up
for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
no way of wiring up AuthenticationMechanisms. I see no other undertow
specific config except for undertow-handlers.conf.
9:59 p.m.
Keep me up to date on this. I'll be using the IdentityManager override
approach with the current codebase for the moment.
On 8/15/2013 8:56 AM, Darran Lofthouse wrote:
I will put something together shortly for the mechanism overrides, I
previously proposed a solution to these lists a while back which
received quite a bit of support.
Overall mechanism overrides will either be possible using the subsystem
configuration or deployment specific configuration providing both ways
to set the mechanism for the app being deployed.
Regards,
Darran Lofthouse.
On 15/08/13 01:23, Bill Burke wrote:
> I'm looking at Undertow handlers and Auth mechanisms and trying to
> figure out how to port resteasy oauth. I need to be able to do the
> following
>
> 1. check a cookie to see if user is already logged in.
> 2. If not redirect to auth server
> 3. get a redirect back from auth server
> 4. make an HTTP request to server based on information from the request
> 5. Obtain a token from this request
> 6. Parse and validate the token to obtain user identity and role mappings
> 7. Propagate the identity and role mappings so other layers can do their
> thing (like role checks)
>
> I can do most of this within a AuthenticationMechanism. sendChallenge()
> would be used to send the redirect to the auth server. I think a custom
> IdentityManager is needed. This would accept a custom Credential. The
> Credential would have the identity and role mappings within it and the
> IdentityManager would allocate an Account based on this information.
>
> So, thats for Undertow....but I don't see any way to wire this all up
> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
> no way of wiring up AuthenticationMechanisms. I see no other undertow
> specific config except for undertow-handlers.conf.
>
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:37 p.m.
Keep me up to date on this. I'll be using the IdentityManager override
approach with the current codebase for the moment.
I have made some changes that should make this easier for you.
On 8/15/2013 8:56 AM, Darran Lofthouse wrote:
> I will put something together shortly for the mechanism overrides, I
> previously proposed a solution to these lists a while back which
> received quite a bit of support.
>
> Overall mechanism overrides will either be possible using the subsystem
> configuration or deployment specific configuration providing both ways
> to set the mechanism for the app being deployed.
>
> Regards,
> Darran Lofthouse.
>
>
> On 15/08/13 01:23, Bill Burke wrote:
>> I'm looking at Undertow handlers and Auth mechanisms and trying to
>> figure out how to port resteasy oauth. I need to be able to do the
>> following
>>
>> 1. check a cookie to see if user is already logged in.
>> 2. If not redirect to auth server
>> 3. get a redirect back from auth server
>> 4. make an HTTP request to server based on information from the request
>> 5. Obtain a token from this request
>> 6. Parse and validate the token to obtain user identity and role mappings
>> 7. Propagate the identity and role mappings so other layers can do their
>> thing (like role checks)
>>
>> I can do most of this within a AuthenticationMechanism. sendChallenge()
>> would be used to send the redirect to the auth server. I think a custom
>> IdentityManager is needed. This would accept a custom Credential. The
>> Credential would have the identity and role mappings within it and the
>> IdentityManager would allocate an Account based on this information.
>>
>> So, thats for Undertow....but I don't see any way to wire this all up
>> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
>> no way of wiring up AuthenticationMechanisms. I see no other undertow
>> specific config except for undertow-handlers.conf.
>>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
11:38 p.m.
Keep me up to date on this. I'll be using the IdentityManager override
approach with the current codebase for the moment.
I have made some changes that should make this easier for you:
https://github.com/wildfly/wildfly/pull/4924/files
Basically the principalVsRoleMap is now stored in the DeploymentInfo, and it is no longer
used by the IdentityManager.
Stuart
On 8/15/2013 8:56 AM, Darran Lofthouse wrote:
> I will put something together shortly for the mechanism overrides, I
> previously proposed a solution to these lists a while back which
> received quite a bit of support.
>
> Overall mechanism overrides will either be possible using the subsystem
> configuration or deployment specific configuration providing both ways
> to set the mechanism for the app being deployed.
>
> Regards,
> Darran Lofthouse.
>
>
> On 15/08/13 01:23, Bill Burke wrote:
>> I'm looking at Undertow handlers and Auth mechanisms and trying to
>> figure out how to port resteasy oauth. I need to be able to do the
>> following
>>
>> 1. check a cookie to see if user is already logged in.
>> 2. If not redirect to auth server
>> 3. get a redirect back from auth server
>> 4. make an HTTP request to server based on information from the request
>> 5. Obtain a token from this request
>> 6. Parse and validate the token to obtain user identity and role mappings
>> 7. Propagate the identity and role mappings so other layers can do their
>> thing (like role checks)
>>
>> I can do most of this within a AuthenticationMechanism. sendChallenge()
>> would be used to send the redirect to the auth server. I think a custom
>> IdentityManager is needed. This would accept a custom Credential. The
>> Credential would have the identity and role mappings within it and the
>> IdentityManager would allocate an Account based on this information.
>>
>> So, thats for Undertow....but I don't see any way to wire this all up
>> for Wildfly. The IdentityManager is hardcoded to a JaaS one and I see
>> no way of wiring up AuthenticationMechanisms. I see no other undertow
>> specific config except for undertow-handlers.conf.
>>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
11:20 p.m.
On 8/15/2013 10:38 AM, Stuart Douglas wrote:
>
> Keep me up to date on this. I'll be using the IdentityManager override
> approach with the current codebase for the moment.
I have made some changes that should make this easier for you:
https://github.com/wildfly/wildfly/pull/4924/files
Basically the principalVsRoleMap is now stored in the DeploymentInfo, and it is no longer
used by the IdentityManager.
Not exactly sure yet what you did. Was this just a refactoring to make
IdentityManager impls easier?
Thanks
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:23 p.m.
Basically it just moved the hacky principle vs role mapping stuff out of the IDM.
Stuart
On 8/15/2013 10:38 AM, Stuart Douglas wrote:
>
>>
>> Keep me up to date on this. I'll be using the IdentityManager override
>> approach with the current codebase for the moment.
>
> I have made some changes that should make this easier for you:
>
> https://github.com/wildfly/wildfly/pull/4924/files
>
> Basically the principalVsRoleMap is now stored in the DeploymentInfo, and
> it is no longer used by the IdentityManager.
>
Not exactly sure yet what you did. Was this just a refactoring to make
IdentityManager impls easier?
Thanks
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:32 p.m.
Ok, wasn't sure if it was more than that.
On 8/16/2013 10:23 AM, Stuart Douglas wrote:
Basically it just moved the hacky principle vs role mapping stuff out of the IDM.
Stuart
>
> On 8/15/2013 10:38 AM, Stuart Douglas wrote:
>>
>>>
>>> Keep me up to date on this. I'll be using the IdentityManager override
>>> approach with the current codebase for the moment.
>>
>> I have made some changes that should make this easier for you:
>>
>> https://github.com/wildfly/wildfly/pull/4924/files
>>
>> Basically the principalVsRoleMap is now stored in the DeploymentInfo, and
>> it is no longer used by the IdentityManager.
>>
>
> Not exactly sure yet what you did. Was this just a refactoring to make
> IdentityManager impls easier?
>
> Thanks
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:50 a.m.
New subject: Account.getRoles()?
Any way we could have an Account.getRoles()?
One of the things Resteasy OAuth integration can do with AS7 is turn an
existing SecurityDomain into an OAuth server with SkeletonKey tokens.
To do this though I need to be able to extract the user's role mappings
after authentication. For AS7, this can be extracted from the
Principal. For Undertow only though, Account has no getRoles() method.
Can you add Set<String> getRoles() to Account?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:13 a.m.
New subject: Account.getRoles()?
For your use case don't you need to use a custom IdentityManager anyway? If so you can
just have getRoles() on your account implementation and cast it.
Stuart
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: undertow-dev(a)lists.jboss.org
Sent: Friday, 16 August, 2013 5:50:00 PM
Subject: [undertow-dev] Account.getRoles()?
Any way we could have an Account.getRoles()?
One of the things Resteasy OAuth integration can do with AS7 is turn an
existing SecurityDomain into an OAuth server with SkeletonKey tokens.
To do this though I need to be able to extract the user's role mappings
after authentication. For AS7, this can be extracted from the
Principal. For Undertow only though, Account has no getRoles() method.
Can you add Set<String> getRoles() to Account?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:18 a.m.
New subject: Account.getRoles()?
Yes, but this is a separate case where I want to create an OAuth server
on top of an existing security domain. So, the custom IdentityManager
would be delegating to the configured one.
On 8/16/2013 12:13 PM, Stuart Douglas wrote:
For your use case don't you need to use a custom IdentityManager
anyway? If so you can just have getRoles() on your account implementation and cast it.
Stuart
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Friday, 16 August, 2013 5:50:00 PM
> Subject: [undertow-dev] Account.getRoles()?
>
> Any way we could have an Account.getRoles()?
>
> One of the things Resteasy OAuth integration can do with AS7 is turn an
> existing SecurityDomain into an OAuth server with SkeletonKey tokens.
> To do this though I need to be able to extract the user's role mappings
> after authentication. For AS7, this can be extracted from the
> Principal. For Undertow only though, Account has no getRoles() method.
>
> Can you add Set<String> getRoles() to Account?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:46 p.m.
New subject: Account.getRoles()?
Done, I should have a release with this in it in the next few days.
Stuart
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org
Sent: Friday, 16 August, 2013 6:18:43 PM
Subject: Re: [undertow-dev] Account.getRoles()?
Yes, but this is a separate case where I want to create an OAuth server
on top of an existing security domain. So, the custom IdentityManager
would be delegating to the configured one.
On 8/16/2013 12:13 PM, Stuart Douglas wrote:
> For your use case don't you need to use a custom IdentityManager anyway? If
> so you can just have getRoles() on your account implementation and cast
> it.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: undertow-dev(a)lists.jboss.org
>> Sent: Friday, 16 August, 2013 5:50:00 PM
>> Subject: [undertow-dev] Account.getRoles()?
>>
>> Any way we could have an Account.getRoles()?
>>
>> One of the things Resteasy OAuth integration can do with AS7 is turn an
>> existing SecurityDomain into an OAuth server with SkeletonKey tokens.
>> To do this though I need to be able to extract the user's role mappings
>> after authentication. For AS7, this can be extracted from the
>> Principal. For Undertow only though, Account has no getRoles() method.
>>
>> Can you add Set<String> getRoles() to Account?
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3914
days inactive
3918
days old
15 comments
3 participants
participants (3)
-
Bill Burke -
Darran Lofthouse -
Stuart Douglas