You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Ciancetta, Jesse E." <jc...@mitre.org> on 2009/07/24 19:58:03 UTC
Secure Tokens in Java Shindig
Hi,
I'm trying to enable secure tokens with the Java version of Shindig (1.0 release) and have run into an issue. The problem is that I can't seem to find a way to enable secure tokens without either (1) modifying the value of the "gadgets.securityTokenType" property directly in the default container.js file or (2) copying the entire container.js file and then configuring the shindig.properties file to load my custom copy instead of the default.
I understand the mechanics around creating custom container configurations and how to take advantage of the nice inheritance framework that Shindig provides for doing that (which seems to have been built specifically to keep from having to copy or modify the container.js file directly), but the problem seems to be that in the constructor of the DefaultSecurityTokenDecoder class, it decides once and for all (for all containers) whether to use BasicSecurityTokenDecoder's (insecure) or BlobCrypterSecurityTokenDecoder's (secure) based on the value of the "gadgets.securityTokenType" property for the "default" container configuration.
I've tried to create a custom container configuration that overrides the required properties for the "default" container like this:
{"gadgets.container" : ["default"],
"gadgets.securityTokenType" : "secure",
"gadgets.securityTokenKeyFile" : "/some/dir/someKey.txt"}
and added a pointer to it to the list of containers in the shindig.properties file, but that just seemed to confuse the container configuration inheritance framework.
Is there some other way to do this without having to directly modify or copy the default container.js file?
Thanks!
--Jesse
RE: Secure Tokens in Java Shindig
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
I had considered doing that too -- I was thinking of binding the BlobCrypterSecurityTokenDecoder directly, but unless I do something to change the configuration for the "default" container in container.js, the BlobCrypterSecurityTokenDecoder constructor is going to end up throwing an exception when it processes the "default" container since there still won't be a key file defined for it. Maybe I could just extend the BlobCrypterSecurityTokenDecoder, and in my implementation I could just ignore the "default" container all together...
Anyhow -- thanks for the feedback!
--Jesse
-----Original Message-----
From: Tim Moore [mailto:tmoore@atlassian.com]
Sent: Friday, July 24, 2009 2:03 PM
To: shindig-dev@incubator.apache.org
Subject: Re: Secure Tokens in Java Shindig
I don't know if this is a recommended approach, but we ended up
bypassing DefaultSecurityTokenDecoder entirely by binding our chosen
SecurityTokenDecoder implementation directly in Guice. In that case,
it doesn't even look at the gadgets.securityTokenType property.
-- Tim
On Jul 24, 2009, at 10:58 AM, Ciancetta, Jesse E. wrote:
> Hi,
>
> I'm trying to enable secure tokens with the Java version of Shindig
> (1.0 release) and have run into an issue. The problem is that I
> can't seem to find a way to enable secure tokens without either (1)
> modifying the value of the "gadgets.securityTokenType" property
> directly in the default container.js file or (2) copying the entire
> container.js file and then configuring the shindig.properties file
> to load my custom copy instead of the default.
>
> I understand the mechanics around creating custom container
> configurations and how to take advantage of the nice inheritance
> framework that Shindig provides for doing that (which seems to have
> been built specifically to keep from having to copy or modify the
> container.js file directly), but the problem seems to be that in the
> constructor of the DefaultSecurityTokenDecoder class, it decides
> once and for all (for all containers) whether to use
> BasicSecurityTokenDecoder's (insecure) or
> BlobCrypterSecurityTokenDecoder's (secure) based on the value of the
> "gadgets.securityTokenType" property for the "default" container
> configuration.
>
> I've tried to create a custom container configuration that overrides
> the required properties for the "default" container like this:
>
> {"gadgets.container" : ["default"],
> "gadgets.securityTokenType" : "secure",
> "gadgets.securityTokenKeyFile" : "/some/dir/someKey.txt"}
>
> and added a pointer to it to the list of containers in the
> shindig.properties file, but that just seemed to confuse the
> container configuration inheritance framework.
>
> Is there some other way to do this without having to directly modify
> or copy the default container.js file?
>
> Thanks!
>
> --Jesse
Re: Secure Tokens in Java Shindig
Posted by Tim Moore <tm...@atlassian.com>.
I don't know if this is a recommended approach, but we ended up
bypassing DefaultSecurityTokenDecoder entirely by binding our chosen
SecurityTokenDecoder implementation directly in Guice. In that case,
it doesn't even look at the gadgets.securityTokenType property.
-- Tim
On Jul 24, 2009, at 10:58 AM, Ciancetta, Jesse E. wrote:
> Hi,
>
> I'm trying to enable secure tokens with the Java version of Shindig
> (1.0 release) and have run into an issue. The problem is that I
> can't seem to find a way to enable secure tokens without either (1)
> modifying the value of the "gadgets.securityTokenType" property
> directly in the default container.js file or (2) copying the entire
> container.js file and then configuring the shindig.properties file
> to load my custom copy instead of the default.
>
> I understand the mechanics around creating custom container
> configurations and how to take advantage of the nice inheritance
> framework that Shindig provides for doing that (which seems to have
> been built specifically to keep from having to copy or modify the
> container.js file directly), but the problem seems to be that in the
> constructor of the DefaultSecurityTokenDecoder class, it decides
> once and for all (for all containers) whether to use
> BasicSecurityTokenDecoder's (insecure) or
> BlobCrypterSecurityTokenDecoder's (secure) based on the value of the
> "gadgets.securityTokenType" property for the "default" container
> configuration.
>
> I've tried to create a custom container configuration that overrides
> the required properties for the "default" container like this:
>
> {"gadgets.container" : ["default"],
> "gadgets.securityTokenType" : "secure",
> "gadgets.securityTokenKeyFile" : "/some/dir/someKey.txt"}
>
> and added a pointer to it to the list of containers in the
> shindig.properties file, but that just seemed to confuse the
> container configuration inheritance framework.
>
> Is there some other way to do this without having to directly modify
> or copy the default container.js file?
>
> Thanks!
>
> --Jesse
Re: Secure Tokens in Java Shindig
Posted by Kevin Brown <et...@google.com>.
On Fri, Jul 24, 2009 at 10:58 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
> Hi,
>
> I'm trying to enable secure tokens with the Java version of Shindig (1.0
> release) and have run into an issue. The problem is that I can't seem to
> find a way to enable secure tokens without either (1) modifying the value of
> the "gadgets.securityTokenType" property directly in the default
> container.js file or (2) copying the entire container.js file and then
> configuring the shindig.properties file to load my custom copy instead of
> the default.
You really should be copying, and probably inheriting from the default. To
do this, you load both, and give yours a unique name. The server will
automatically infer the inheritance between your configuration and
'default'.
>
>
> I understand the mechanics around creating custom container configurations
> and how to take advantage of the nice inheritance framework that Shindig
> provides for doing that (which seems to have been built specifically to keep
> from having to copy or modify the container.js file directly), but the
> problem seems to be that in the constructor of the
> DefaultSecurityTokenDecoder class, it decides once and for all (for all
> containers) whether to use BasicSecurityTokenDecoder's (insecure) or
> BlobCrypterSecurityTokenDecoder's (secure) based on the value of the
> "gadgets.securityTokenType" property for the "default" container
> configuration.
Yeah, that sounds like a stupid bug. You should file a JIRA ticket for it.
>
>
> I've tried to create a custom container configuration that overrides the
> required properties for the "default" container like this:
>
> {"gadgets.container" : ["default"],
> "gadgets.securityTokenType" : "secure",
> "gadgets.securityTokenKeyFile" : "/some/dir/someKey.txt"}
>
> and added a pointer to it to the list of containers in the
> shindig.properties file, but that just seemed to confuse the container
> configuration inheritance framework.
>
> Is there some other way to do this without having to directly modify or
> copy the default container.js file?
>
> Thanks!
>
> --Jesse
>