12:33 p.m.
Hello all,
Starting this e-mail thread as I want to raise the option of reducing
the use of the IdentityManager [1] within Undertow[2]. At the moment I
think it at risk of becoming another general purpose IDM API/SPI which
was never it's intention.
The purpose of this IdentityManager was as an SPI to define the
verification methods required by the authentication mechanisms included
in Undertow. By providing it in this way the core of Undertow would not
be dependent on any specific IDM implementation.
Short term within WildFly we have implementations of this that wrap by
the management security realms and the existing JAAS domains - longer
term we will only be wrapping PicketLink IDM.
In the past the question has been raised, "Why not just use PicketLink
IDM directly?". From an Undertow perspective the reason is so that we
can use different IDM implementations and transition from what we have
today in WildFly to purely using PicketLink IDM, also the core of
Undertow is not dependent on any specific implementation.
For any additional authentication mechanisms being added there is no
need for them to use this as an API and encouraging mechanisms to use
this encourages that this interface is going to increase in complexity.
What I am looking to do now is to remove access to this interface from
the SecurityContext and instead leave it to be retrieved as an
attachment from the HttpServerExchange. The WildFly integration will
then take on the responsibility of ensuring the appropriate
implementation is attached to the exchange.
Where authentication mechanisms are added that require access to more
advanced IDM capabilities then the IDM required should be attached to
the exchange and the mechanism use it directly.
From an Undertow perspective this just leaves one small interface that
needs to be implemented so that the authentication mechanism can
register the authenticated identity with the current request: -
void authenticationComplete(final Account account, final String
mechanismName);
As I type this e-mail I realise I may have one further option - remove
the IdentityManager interface entirely and instead make each
authentication mechanism abstract with a verify method. As we integrate
in WildFly we extend each mechanism to provide the implementation of the
verify methods.
Either way I do not think Undertow is the correct location for a new
general purpose IdentityManager API, if we truly need that then it
should be split out into it's own module so that it can also be used
outside of HTTP e.g. SASL.
Regards,
Darran Lofthouse.
1 - https://community.jboss.org/wiki/Undertow-IdentityManager
2 - https://issues.jboss.org/browse/UNDERTOW-65
12:59 p.m.
One thing I want to stress, is that Undertow was intended to be usable as a standalone
project, and it should be possible for someone like Bill to develop an OAuth solution on
it that he can run through a unit test. It's perfectly reasonable to have certain
advanced features be AS only, but the project itself still needs to provide support for
security.
This could very well mean we have a few duplicative SPIs, but as long as we do not have a
performance penalty and they don't prevent the use of proper AS integration I just
don't see a problem with them.
On May 30, 2013, at 12:33 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
Hello all,
Starting this e-mail thread as I want to raise the option of reducing
the use of the IdentityManager [1] within Undertow[2]. At the moment I
think it at risk of becoming another general purpose IDM API/SPI which
was never it's intention.
The purpose of this IdentityManager was as an SPI to define the
verification methods required by the authentication mechanisms included
in Undertow. By providing it in this way the core of Undertow would not
be dependent on any specific IDM implementation.
Short term within WildFly we have implementations of this that wrap by
the management security realms and the existing JAAS domains - longer
term we will only be wrapping PicketLink IDM.
In the past the question has been raised, "Why not just use PicketLink
IDM directly?". From an Undertow perspective the reason is so that we
can use different IDM implementations and transition from what we have
today in WildFly to purely using PicketLink IDM, also the core of
Undertow is not dependent on any specific implementation.
For any additional authentication mechanisms being added there is no
need for them to use this as an API and encouraging mechanisms to use
this encourages that this interface is going to increase in complexity.
What I am looking to do now is to remove access to this interface from
the SecurityContext and instead leave it to be retrieved as an
attachment from the HttpServerExchange. The WildFly integration will
then take on the responsibility of ensuring the appropriate
implementation is attached to the exchange.
Where authentication mechanisms are added that require access to more
advanced IDM capabilities then the IDM required should be attached to
the exchange and the mechanism use it directly.
From an Undertow perspective this just leaves one small interface that
needs to be implemented so that the authentication mechanism can
register the authenticated identity with the current request: -
void authenticationComplete(final Account account, final String
mechanismName);
As I type this e-mail I realise I may have one further option - remove
the IdentityManager interface entirely and instead make each
authentication mechanism abstract with a verify method. As we integrate
in WildFly we extend each mechanism to provide the implementation of the
verify methods.
Either way I do not think Undertow is the correct location for a new
general purpose IdentityManager API, if we truly need that then it
should be split out into it's own module so that it can also be used
outside of HTTP e.g. SASL.
Regards,
Darran Lofthouse.
1 - https://community.jboss.org/wiki/Undertow-IdentityManager
2 - https://issues.jboss.org/browse/UNDERTOW-65
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3:24 p.m.
Right, Jason. It is not just Bill. I need Undertow as my embedded web
container for junit testing. Currently I use Jetty.
Apart from the standard security mechanisms in Undertow, I need the
ability to plug in my custom security stuff into UT in a junit environment.
Coming back to Darran's email, please see inline.
On 05/30/2013 12:59 PM, Jason Greene wrote:
One thing I want to stress, is that Undertow was intended to be
usable as a standalone project, and it should be possible for someone like Bill to develop
an OAuth solution on it that he can run through a unit test. It's perfectly reasonable
to have certain advanced features be AS only, but the project itself still needs to
provide support for security.
This could very well mean we have a few duplicative SPIs, but as long as we do not have a
performance penalty and they don't prevent the use of proper AS integration I just
don't see a problem with them.
On May 30, 2013, at 12:33 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
> Hello all,
>
> Starting this e-mail thread as I want to raise the option of reducing
> the use of the IdentityManager [1] within Undertow[2]. At the moment I
> think it at risk of becoming another general purpose IDM API/SPI which
> was never it's intention.
>
A simple IDM API in Undertow should be ok as long as there is an ability to
replace the IDM implementation with something more extensive (such as
PicketLink IDM)
via API calls on Undertow. Wildfly can then use the same Undertow API to
replace IDM default impl.
From PicketLink perspective, maybe we can provide some form of a driver
(picketlink-idm-undertow)
that users can use to install PL IDM in Undertow. This driver will be
bridge between UT IDM API and
PL IDM API.
> The purpose of this IdentityManager was as an SPI to define the
> verification methods required by the authentication mechanisms included
> in Undertow. By providing it in this way the core of Undertow would not
> be dependent on any specific IDM implementation.
>
> Short term within WildFly we have implementations of this that wrap by
> the management security realms and the existing JAAS domains - longer
> term we will only be wrapping PicketLink IDM.
>
> In the past the question has been raised, "Why not just use PicketLink
> IDM directly?". From an Undertow perspective the reason is so that we
> can use different IDM implementations and transition from what we have
> today in WildFly to purely using PicketLink IDM, also the core of
> Undertow is not dependent on any specific implementation.
>
> For any additional authentication mechanisms being added there is no
> need for them to use this as an API and encouraging mechanisms to use
> this encourages that this interface is going to increase in complexity.
>
> What I am looking to do now is to remove access to this interface from
> the SecurityContext and instead leave it to be retrieved as an
> attachment from the HttpServerExchange. The WildFly integration will
> then take on the responsibility of ensuring the appropriate
> implementation is attached to the exchange.
>
> Where authentication mechanisms are added that require access to more
> advanced IDM capabilities then the IDM required should be attached to
> the exchange and the mechanism use it directly.
>
> From an Undertow perspective this just leaves one small interface that
> needs to be implemented so that the authentication mechanism can
> register the authenticated identity with the current request: -
>
> void authenticationComplete(final Account account, final String
> mechanismName);
>
> As I type this e-mail I realise I may have one further option - remove
> the IdentityManager interface entirely and instead make each
> authentication mechanism abstract with a verify method. As we integrate
> in WildFly we extend each mechanism to provide the implementation of the
> verify methods.
>
> Either way I do not think Undertow is the correct location for a new
> general purpose IdentityManager API, if we truly need that then it
> should be split out into it's own module so that it can also be used
> outside of HTTP e.g. SASL.
>
> Regards,
> Darran Lofthouse.
>
> 1 - https://community.jboss.org/wiki/Undertow-IdentityManager
> 2 - https://issues.jboss.org/browse/UNDERTOW-65
6:42 p.m.
New subject: unit testing was Re: Reducing Use of Undertow IdentityManager
On 5/30/2013 4:24 PM, Anil Saldhana wrote:
Right, Jason. It is not just Bill. I need Undertow as my embedded
web
container for junit testing. Currently I use Jetty.
I'm currently using Jetty for my servlet integration tests but am going
to switch to using Wildfly as soon as the next JBoss Modules is released
and shipped with Wildfly. The "mavenized modules" feature I added to
JBoss Modules allows you to run unit tests without having to extract
170m of jboss distro with each maven module you're are testing with.
I've already prototyped it and it works pretty good. Its a little
slower than Jetty, specifically in the shutdown phase, but its good
enough to be able to replace jetty.
It will also be cool to replace the TJWS micro-servlet container I use
for in-browser unit testing. But Undertow is going to have to beat the
sub-microsecond startup and shutdown time of TJWS for me to replace it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:22 a.m.
New subject: unit testing was Re: Reducing Use of Undertow IdentityManager
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: undertow-dev(a)lists.jboss.org
Sent: Friday, 31 May, 2013 9:42:13 AM
Subject: [undertow-dev] unit testing was Re: Reducing Use of Undertow IdentityManager
On 5/30/2013 4:24 PM, Anil Saldhana wrote:
> Right, Jason. It is not just Bill. I need Undertow as my embedded web
> container for junit testing. Currently I use Jetty.
>
I'm currently using Jetty for my servlet integration tests but am going
to switch to using Wildfly as soon as the next JBoss Modules is released
and shipped with Wildfly. The "mavenized modules" feature I added to
JBoss Modules allows you to run unit tests without having to extract
170m of jboss distro with each maven module you're are testing with.
I've already prototyped it and it works pretty good. Its a little
slower than Jetty, specifically in the shutdown phase, but its good
enough to be able to replace jetty.
It will also be cool to replace the TJWS micro-servlet container I use
for in-browser unit testing. But Undertow is going to have to beat the
sub-microsecond startup and shutdown time of TJWS for me to replace it.
long s = System.currentTimeMillis();
Undertow server = Undertow.builder()
.addListener(8080, "localhost")
.setDefaultHandler(new HttpHandler() {
@Override
public void handleRequest(final HttpServerExchange exchange) throws Exception
{
exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
"text/plain");
exchange.getResponseSender().send("Hello World");
}
}).build();
server.start();
long f = System.currentTimeMillis();
System.out.print("Time was " + (f - s) + "ms\n");
Results in
Time was 14ms
So way to slow, not even close to microsecond territory :-)
Not sure what the time is spend on, probably class loading and binding to the socket.
We use an embedded Undertow container in our test suite, and the servlet tests seem to
take about 0.02s accourding to JUnit, which generally involves setting up a servlet
deployment
and making at least one HTTP request.
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
6:35 a.m.
New subject: unit testing was Re: Reducing Use of Undertow IdentityManager
On 5/31/2013 1:22 AM, Stuart Douglas wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Friday, 31 May, 2013 9:42:13 AM
> Subject: [undertow-dev] unit testing was Re: Reducing Use of
Undertow IdentityManager
>
>
>
> On 5/30/2013 4:24 PM, Anil Saldhana wrote:
>> Right, Jason. It is not just Bill. I need Undertow as my embedded web
>> container for junit testing. Currently I use Jetty.
>>
>
> I'm currently using Jetty for my servlet integration tests but am going
> to switch to using Wildfly as soon as the next JBoss Modules is released
> and shipped with Wildfly. The "mavenized modules" feature I added to
> JBoss Modules allows you to run unit tests without having to extract
> 170m of jboss distro with each maven module you're are testing with.
> I've already prototyped it and it works pretty good. Its a little
> slower than Jetty, specifically in the shutdown phase, but its good
> enough to be able to replace jetty.
>
> It will also be cool to replace the TJWS micro-servlet container I use
> for in-browser unit testing. But Undertow is going to have to beat the
> sub-microsecond startup and shutdown time of TJWS for me to replace it.
long s = System.currentTimeMillis();
Undertow server = Undertow.builder()
.addListener(8080, "localhost")
.setDefaultHandler(new HttpHandler() {
@Override
public void handleRequest(final HttpServerExchange exchange) throws Exception
{
exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
"text/plain");
exchange.getResponseSender().send("Hello World");
}
}).build();
server.start();
long f = System.currentTimeMillis();
System.out.print("Time was " + (f - s) + "ms\n");
Results in
Time was 14ms
So way to slow, not even close to microsecond territory :-)
Not sure what the time is spend on, probably class loading and binding to the socket.
We use an embedded Undertow container in our test suite, and the servlet tests seem to
take about 0.02s accourding to JUnit, which generally involves setting up a servlet
deployment
and making at least one HTTP request.
Maybe I was exagerating on the sub microsecond. 14ms is good enough.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:33 p.m.
I don't think these undertow SPIs need be that complex. JBossWeb
security valves delegate to a Realm. A realm which handles
authentication and the setting of role mapppings. This has a lot of
limitations and is not very flexible.
Instead, allow the security valve to set the subject/principal and
provide a callback for isUserInRole(). A good example is the JAX-RS
SecurityContext.
interface SecurityContext {
public Principal getUserPrincipal();
public boolean isUserInRole(String role);
}
Filter implementations can implement the SecurityContext interface
themselves and override it for the request. Really really simple.
Undertow doesn't have to support much, and yet you have a lot of
flexibility. You're letting the security plugin given Undertow what it
needs to execute securely instead of guessing what SPI the security
plugin might need to run.
Combine this with Stuarts idea of a "feature" component that can be
bound via the auth-method and you have an extremely simple yet powerful SPI.
Am I making any sense?
On 5/30/2013 1:59 PM, Jason Greene wrote:
One thing I want to stress, is that Undertow was intended to be
usable as a standalone project, and it should be possible for someone like Bill to develop
an OAuth solution on it that he can run through a unit test. It's perfectly reasonable
to have certain advanced features be AS only, but the project itself still needs to
provide support for security.
This could very well mean we have a few duplicative SPIs, but as long as we do not have a
performance penalty and they don't prevent the use of proper AS integration I just
don't see a problem with them.
On May 30, 2013, at 12:33 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
> Hello all,
>
> Starting this e-mail thread as I want to raise the option of reducing
> the use of the IdentityManager [1] within Undertow[2]. At the moment I
> think it at risk of becoming another general purpose IDM API/SPI which
> was never it's intention.
>
> The purpose of this IdentityManager was as an SPI to define the
> verification methods required by the authentication mechanisms included
> in Undertow. By providing it in this way the core of Undertow would not
> be dependent on any specific IDM implementation.
>
> Short term within WildFly we have implementations of this that wrap by
> the management security realms and the existing JAAS domains - longer
> term we will only be wrapping PicketLink IDM.
>
> In the past the question has been raised, "Why not just use PicketLink
> IDM directly?". From an Undertow perspective the reason is so that we
> can use different IDM implementations and transition from what we have
> today in WildFly to purely using PicketLink IDM, also the core of
> Undertow is not dependent on any specific implementation.
>
> For any additional authentication mechanisms being added there is no
> need for them to use this as an API and encouraging mechanisms to use
> this encourages that this interface is going to increase in complexity.
>
> What I am looking to do now is to remove access to this interface from
> the SecurityContext and instead leave it to be retrieved as an
> attachment from the HttpServerExchange. The WildFly integration will
> then take on the responsibility of ensuring the appropriate
> implementation is attached to the exchange.
>
> Where authentication mechanisms are added that require access to more
> advanced IDM capabilities then the IDM required should be attached to
> the exchange and the mechanism use it directly.
>
> From an Undertow perspective this just leaves one small interface that
> needs to be implemented so that the authentication mechanism can
> register the authenticated identity with the current request: -
>
> void authenticationComplete(final Account account, final String
> mechanismName);
>
> As I type this e-mail I realise I may have one further option - remove
> the IdentityManager interface entirely and instead make each
> authentication mechanism abstract with a verify method. As we integrate
> in WildFly we extend each mechanism to provide the implementation of the
> verify methods.
>
> Either way I do not think Undertow is the correct location for a new
> general purpose IdentityManager API, if we truly need that then it
> should be split out into it's own module so that it can also be used
> outside of HTTP e.g. SASL.
>
> Regards,
> Darran Lofthouse.
>
> 1 - https://community.jboss.org/wiki/Undertow-IdentityManager
> 2 - https://issues.jboss.org/browse/UNDERTOW-65
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
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
12:46 a.m.
Bill Burke wrote:
I don't think these undertow SPIs need be that complex.
JBossWeb
security valves delegate to a Realm. A realm which handles
authentication and the setting of role mapppings. This has a lot of
limitations and is not very flexible.
Instead, allow the security valve to set the subject/principal and
provide a callback for isUserInRole(). A good example is the JAX-RS
SecurityContext.
interface SecurityContext {
public Principal getUserPrincipal();
public boolean isUserInRole(String role);
}
This is basically what Darran is proposing, after his changes the
Account interface will look the same as above.
I am not 100% convinced that this is a good idea though. This means that
most custom authentication mechanisms will be relying on having a
specific external IDM implementation, so it won't really be possible to
write a custom pure Undertow authentication mechanism, it will always be
Undertow + Picketlink, or Undertow + Wildfly, and if you want a truly
standalone auth mechanism you will basically have to create your own IDM
interface to allow the identity store to plug in.
I am worried that if we don't have a standard Undertow IDM interface
everyone is just going to invent their own as needed, and it will turn
into a bit of a mess.
We also need to think about the embedded case, if you are using Undertow
as a standalone server you will definitely not want Wildfly
dependencies, and probably won't want to bring in all of Picketlink either.
I don't mind the idea of having a general purpose IDM module though.
Potentially you could have this small general purpose one just provide
the basic methods, and Picketlink provide a more full featured one that
extends it. This means you would not need any sort of IDM bridge to make
Undertow work with Picketlink, without them depending on each other.
Stuart
Filter implementations can implement the SecurityContext interface
themselves and override it for the request. Really really simple.
Undertow doesn't have to support much, and yet you have a lot of
flexibility. You're letting the security plugin given Undertow what it
needs to execute securely instead of guessing what SPI the security
plugin might need to run.
Combine this with Stuarts idea of a "feature" component that can be
bound via the auth-method and you have an extremely simple yet powerful SPI.
Am I making any sense?
On 5/30/2013 1:59 PM, Jason Greene wrote:
> One thing I want to stress, is that Undertow was intended to be usable as a
standalone project, and it should be possible for someone like Bill to develop an OAuth
solution on it that he can run through a unit test. It's perfectly reasonable to have
certain advanced features be AS only, but the project itself still needs to provide
support for security.
>
> This could very well mean we have a few duplicative SPIs, but as long as we do not
have a performance penalty and they don't prevent the use of proper AS integration I
just don't see a problem with them.
>
> On May 30, 2013, at 12:33 PM, Darran Lofthouse<darran.lofthouse(a)jboss.com>
wrote:
>
>> Hello all,
>>
>> Starting this e-mail thread as I want to raise the option of reducing
>> the use of the IdentityManager [1] within Undertow[2]. At the moment I
>> think it at risk of becoming another general purpose IDM API/SPI which
>> was never it's intention.
>>
>> The purpose of this IdentityManager was as an SPI to define the
>> verification methods required by the authentication mechanisms included
>> in Undertow. By providing it in this way the core of Undertow would not
>> be dependent on any specific IDM implementation.
>>
>> Short term within WildFly we have implementations of this that wrap by
>> the management security realms and the existing JAAS domains - longer
>> term we will only be wrapping PicketLink IDM.
>>
>> In the past the question has been raised, "Why not just use PicketLink
>> IDM directly?". From an Undertow perspective the reason is so that we
>> can use different IDM implementations and transition from what we have
>> today in WildFly to purely using PicketLink IDM, also the core of
>> Undertow is not dependent on any specific implementation.
>>
>> For any additional authentication mechanisms being added there is no
>> need for them to use this as an API and encouraging mechanisms to use
>> this encourages that this interface is going to increase in complexity.
>>
>> What I am looking to do now is to remove access to this interface from
>> the SecurityContext and instead leave it to be retrieved as an
>> attachment from the HttpServerExchange. The WildFly integration will
>> then take on the responsibility of ensuring the appropriate
>> implementation is attached to the exchange.
>>
>> Where authentication mechanisms are added that require access to more
>> advanced IDM capabilities then the IDM required should be attached to
>> the exchange and the mechanism use it directly.
>>
>> From an Undertow perspective this just leaves one small interface that
>> needs to be implemented so that the authentication mechanism can
>> register the authenticated identity with the current request: -
>>
>> void authenticationComplete(final Account account, final String
>> mechanismName);
>>
>> As I type this e-mail I realise I may have one further option - remove
>> the IdentityManager interface entirely and instead make each
>> authentication mechanism abstract with a verify method. As we integrate
>> in WildFly we extend each mechanism to provide the implementation of the
>> verify methods.
>>
>> Either way I do not think Undertow is the correct location for a new
>> general purpose IdentityManager API, if we truly need that then it
>> should be split out into it's own module so that it can also be used
>> outside of HTTP e.g. SASL.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> 1 - https://community.jboss.org/wiki/Undertow-IdentityManager
>> 2 - https://issues.jboss.org/browse/UNDERTOW-65
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
7:21 a.m.
On 5/31/2013 1:46 AM, Stuart Douglas wrote:
Bill Burke wrote:
> I don't think these undertow SPIs need be that complex. JBossWeb
> security valves delegate to a Realm. A realm which handles
> authentication and the setting of role mapppings. This has a lot of
> limitations and is not very flexible.
>
> Instead, allow the security valve to set the subject/principal and
> provide a callback for isUserInRole(). A good example is the JAX-RS
> SecurityContext.
>
> interface SecurityContext {
> public Principal getUserPrincipal();
> public boolean isUserInRole(String role);
> }
>
This is basically what Darran is proposing, after his changes the
Account interface will look the same as above.
I am not 100% convinced that this is a good idea though.
I hope you mean that you think the simple "SecurityContext" SPI is a
good idea, but not having a more general IDM SPI *in addition* is the
bad idea.
At least for my stuff, my server applications don't even an IDM SPI as
they obtain information from the request. An IDM SPI just gets in the
way. And my Identity Service may not even be able to use an IDM SPI at
the normal integration points because of provisioning issues and the
fact that we want customizable login screens per security domain.
I don't mind the idea of having a general purpose IDM module
though.
Potentially you could have this small general purpose one just provide
the basic methods, and Picketlink provide a more full featured one that
extends it. This means you would not need any sort of IDM bridge to make
Undertow work with Picketlink, without them depending on each other.
I think this general IDM SPI should live in Picketlink as IMO, this is
part of their charter. Of course the necessary interfaces should be
isolated in their own module. Just as DML put the hammer down on
requiring JBoss Logging and XNIO, you should be consistent with the
other core SPIs. If it is a matter of Picketlink underdelivering, then
thats another different conversation that needs to happen.
Its your baby, your decision, but I at least want the small tiny
"SecurityContext" SPI I've been talking about.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:58 p.m.
Bill Burke wrote:
On 5/31/2013 1:46 AM, Stuart Douglas wrote:
>
>
> Bill Burke wrote:
>> I don't think these undertow SPIs need be that complex. JBossWeb
>> security valves delegate to a Realm. A realm which handles
>> authentication and the setting of role mapppings. This has a lot of
>> limitations and is not very flexible.
>>
>> Instead, allow the security valve to set the subject/principal and
>> provide a callback for isUserInRole(). A good example is the JAX-RS
>> SecurityContext.
>>
>> interface SecurityContext {
>> public Principal getUserPrincipal();
>> public boolean isUserInRole(String role);
>> }
>>
>
> This is basically what Darran is proposing, after his changes the
> Account interface will look the same as above.
>
> I am not 100% convinced that this is a good idea though.
I hope you mean that you think the simple "SecurityContext" SPI is a
good idea, but not having a more general IDM SPI *in addition* is the
bad idea.
Yes, sorry I should have been more clear. I am for the minimum security
context SPI, just was not sure about the identity manager changes.
I have been thinking about this all weekend, and I am still not really
sure what the best way to handle this is. For now I think I will merge
Darran's PR with the cut down IDM and see how that works out. I think
that once we have a few custom authentication mechanisms it will be a
lot clearer if a more full featured IDM interface would help, and if so
what form it should take.
Stuart
At least for my stuff, my server applications don't even an IDM SPI as
they obtain information from the request. An IDM SPI just gets in the
way. And my Identity Service may not even be able to use an IDM SPI at
the normal integration points because of provisioning issues and the
fact that we want customizable login screens per security domain.
> I don't mind the idea of having a general purpose IDM module though.
> Potentially you could have this small general purpose one just provide
> the basic methods, and Picketlink provide a more full featured one that
> extends it. This means you would not need any sort of IDM bridge to make
> Undertow work with Picketlink, without them depending on each other.
>
I think this general IDM SPI should live in Picketlink as IMO, this is
part of their charter. Of course the necessary interfaces should be
isolated in their own module. Just as DML put the hammer down on
requiring JBoss Logging and XNIO, you should be consistent with the
other core SPIs. If it is a matter of Picketlink underdelivering, then
thats another different conversation that needs to happen.
Its your baby, your decision, but I at least want the small tiny
"SecurityContext" SPI I've been talking about.
3:31 a.m.
On 02/06/13 23:58, Stuart Douglas wrote:
I have been thinking about this all weekend, and I am still not
really
sure what the best way to handle this is. For now I think I will merge
Darran's PR with the cut down IDM and see how that works out. I think
that once we have a few custom authentication mechanisms it will be a
lot clearer if a more full featured IDM interface would help, and if so
what form it should take.
Once I finish off some of these Undertow tasks I am also going to be
moving onto JBoss SASL which has some changes needed for WildFly and as
I mentioned in my last e-mail is another area with a need for some form
of IdentityManager API/SPI without a specific dependence on an
implementation.
Maybe even PicketLink can provide this bare API/SPI as a separate module
with no implementation. This should also benefit the PicketLink project
if there is a PicketLink 3 an isolated API should make it possible to
upgrade in WildFly without every component needing to be made compatible
with the next PicketLink version.
FYI for those that haven't seen what was PicketLink 3 has now become
PicketLink 2.5.
Regards,
Darran Lofthouse.
5:27 a.m.
There were quite a few replies overnight so I am just going to reply to
my original mail rather than pick one ;-)
As I said in my first e-mail the classes that exist are definitely an
SPI but there does seem to be a lot of support for keeping it available
as an API to be usable at least to cover the mechanisms within Undertow
and the OAuth requirements from Bill.
If that is the case I suggest we split this out into it's own module as
it should not be specific to Undertow / HTTP. We have said for a while
we want to move the SASL mechanisms on from CallbackHandlers as well.
Projects developing IDM solutions such as PicketLink IDM can then just
depend on this API/SPI and create their own implementation.
Both Undertow and Remoting / SASL can make use of this.
So if we went in this direction where should we live, this would not be
specific to any of: -
- PicketLink
- Remoting
- SASL
- Undertow
- WildFly
Regards,
Darran Lofthouse.
On 30/05/13 18:33, Darran Lofthouse wrote:
Hello all,
Starting this e-mail thread as I want to raise the option of reducing
the use of the IdentityManager [1] within Undertow[2]. At the moment I
think it at risk of becoming another general purpose IDM API/SPI which
was never it's intention.
The purpose of this IdentityManager was as an SPI to define the
verification methods required by the authentication mechanisms included
in Undertow. By providing it in this way the core of Undertow would not
be dependent on any specific IDM implementation.
Short term within WildFly we have implementations of this that wrap by
the management security realms and the existing JAAS domains - longer
term we will only be wrapping PicketLink IDM.
In the past the question has been raised, "Why not just use PicketLink
IDM directly?". From an Undertow perspective the reason is so that we
can use different IDM implementations and transition from what we have
today in WildFly to purely using PicketLink IDM, also the core of
Undertow is not dependent on any specific implementation.
For any additional authentication mechanisms being added there is no
need for them to use this as an API and encouraging mechanisms to use
this encourages that this interface is going to increase in complexity.
What I am looking to do now is to remove access to this interface from
the SecurityContext and instead leave it to be retrieved as an
attachment from the HttpServerExchange. The WildFly integration will
then take on the responsibility of ensuring the appropriate
implementation is attached to the exchange.
Where authentication mechanisms are added that require access to more
advanced IDM capabilities then the IDM required should be attached to
the exchange and the mechanism use it directly.
From an Undertow perspective this just leaves one small interface that
needs to be implemented so that the authentication mechanism can
register the authenticated identity with the current request: -
void authenticationComplete(final Account account, final String
mechanismName);
As I type this e-mail I realise I may have one further option - remove
the IdentityManager interface entirely and instead make each
authentication mechanism abstract with a verify method. As we integrate
in WildFly we extend each mechanism to provide the implementation of the
verify methods.
Either way I do not think Undertow is the correct location for a new
general purpose IdentityManager API, if we truly need that then it
should be split out into it's own module so that it can also be used
outside of HTTP e.g. SASL.
Regards,
Darran Lofthouse.
1 - https://community.jboss.org/wiki/Undertow-IdentityManager
2 - https://issues.jboss.org/browse/UNDERTOW-65
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
4107
days inactive
4111
days old
11 comments
5 participants
participants (5)
-
Anil Saldhana -
Bill Burke -
Darran Lofthouse -
Jason Greene -
Stuart Douglas