[wildfly-dev] Push for CORS in WildFly 8

[Darran Lofthouse]

The main problem we have with these solutions is they quickly introduce 
the requirement for the transport to be confidential to prevent 
interception of packets for replays.

Being confidential out of the box is never really an option, any 
solution there is flawed - the best I can think of at the moment is 
adding a set of management ops for key / certificate management and 
updating the console to strongly push the administrator towards enabling 
SSL.

The next issue is that by using standard HTTP authentication mechanisms 
standard APIs can be used in many programming languages to actually call 
the management interface without needing to know about alternative 
authentication schemes.  But having said that supporting it in addition 
to the current mechanisms should not be a problem - best case the 
authentication mechanisms co-exist - worst case we have a second context 
exposed that the console communicates with leaving the existing 
management context as-is.

Regards,
Darran Lofthouse.



On 10/12/13 17:35, Heiko Braun wrote:
> I dont understand your second point, but +1 for enabling cors. It would enable arbitrary use cases that rely on the http endpoint.
>
> But cors is onky one part if the story. The authentication mechanism would need to change as well, to allow for better integration.
>
> Has anyone evaluated keycloak as an alternative for securing the http management endpoint?
>
> At a first glance it seems to solve many of the problems we've outlined before.
>
>
>
>
>> Am 10.12.2013 um 14:17 schrieb ssilvert at redhat.com:
>>
>> No other console is allowed to use the HTTP management endpoint.  So,
>> a layered product's console can not control its own subsystem.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>