Fwd: [hybi] WG: WebSockets in Penetration Testing
by Heiko Braun
FYI
Begin forwarded message:
> From: Tobias Oberstein <tobias.oberstein(a)tavendo.de>
> Subject: [hybi] WG: WebSockets in Penetration Testing
> Date: May 23, 2013 10:29:12 AM GMT+02:00
> To: "hybi(a)ietf.org" <hybi(a)ietf.org>
> Cc: Robert Koch <robert.koch(a)loggia.at>, "autobahnws(a)googlegroups.com" <autobahnws(a)googlegroups.com>
>
> RT for protocol testing nerds: a master thesis and GSoC project about WS penetration testing.
>
> There is also an interesting chapter about WS usage and adoption in Android apps ..
>
>
> Von: Robert Koch [mailto:robert.koch@loggia.at]
> Gesendet: Donnerstag, 23. Mai 2013 08:48
> An: tobias.oberstein(a)gmail.com
> Betreff: WebSockets in Penetration Testing
>
> Hello Tobias,
>
> my master's thesis is now available online:
> Info-Page: http://permalink.obvsg.at/AC07815487
> PDF: http://media.obvsg.at/p-AC07815487-2001
> Feel free to share it as you like. Thanks for helping me out to understand the term "TCP-clean". My master's thesis is based on my Google Summer of Code Project 2012 (http://code.google.com/p/zaproxy/).
>
> Best wishes,
> Robert
> _______________________________________________
> hybi mailing list
> hybi(a)ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
12 years, 4 months
- 1
- 2
Reducing Use of Undertow IdentityManager
by Darran Lofthouse
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 years, 4 months
- 5
- 11