Re: [aerogear-dev] AeroGear Crypto Java 0.1.3 Staged
by Bruno Oliveira
New staging URL https://repository.jboss.org/nexus/content/repositories/jboss_release.... The latest change was to benefit Android and write less code:
- ae454bf Expose method to generate secret for scenarios where it must be saved into the key store
--
abstractj
On March 12, 2014 at 4:57:51 PM, Bruno Oliveira (bruno(a)abstractj.org) wrote:
> Good morning everyone, AG Crypto Java was staged under the following maven profile:
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
> I’m planning to release it on Friday morning (14/03) Changelog: * 17b9787 (upstream-abstractj/keypair-encoding,
> keypair-encoding) Explicit imports, instead of wildcards * 7e595da Accept a raw key
> pair. For scenarios where the public key is transmitted over the wire a34b746 Test refactoring
> * 880be04 Add support on cryptobox to accept a public key for encryption * a2c39ff Testing
> vectors for public key encryption * 4421bc3 (upstream-abstractj/pom, pom) Change
> the scope for bouncycastle * f190d64 (upstream-abstractj/refactor, refactor) Accept
> KeyPair as argument * 832127a (AGSEC-147) Hashing support for SHA-256 and SHA-512 --
> abstractj
11 years
Passphrase encryption - REST API discussion
by Bruno Oliveira
Good morning slackers, moving forward with my attempt to put pants on passphrases. I would like to discuss how the REST API would be with the change, because is better to have feedback instead of work for days and waste some time.
Register push app:
- HTTP request
Remain unchanged
- HTTP response
{"id":"2095ab1a-a569-4ae2-a43c-a86b83041592”,
"name":"MyApp”,
"description":"awesome app”,
"pushApplicationID":"ca99487d-6387-41bd-b393-0ce480977efe”,
"masterSecret":"b315d524-e9f9-4d04-946c-b73278ff29be”,
"developer":"admin”,
"androidVariants":[],
"simplePushVariants":[],
“chromePackagedAppVariants":[],
"publicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEpsPA31qRWrtiAhnpGBzgwoE435c18gD42y13urb0JSdx4AHQRthhAUFVnu+RqUU8NTp9tGnEEhyBZfbV67arVw==“,
“nonce”:”6KbYGZKvTusU+IL3sdY9g=="
"iosvariants":[]}
publicKey: Is the public key created per application and will be optional for developers who do care about security. If for some reason they don’t want to encrypt their passphrase or certificate, that’s ok.
nonce: 16 bytes non-deterministic used to encrypt the data on the server
Note: Both would be stored into UPS database (not perfect, but a good start)
Keep in mind that this is just the initial idea, for example, masterSecret should never return in clear. To the further interactions it will be fixed establishing a key agreement between client and server and encrypt the whole response (only for sensitive data). Yeah, I know, we are protected by SSL, but we shouldn’t trust on it.
iOS Variant:
- HTTP request
Remain unchanged, but now certificate and passphrase can be send encrypted and the server will store it.
- HTTP response
Remain unchaged
Sender:
- HTTP request
Remain unchanged, but now the server will search for the application ID and retrieve the public key to decrypt application's passphrase
- HTTP response
Remain unchanged
AeroGear Clients
- cURL
Yesterday I had the amusing experience of dig into the sources of OpenSSL and their documentation, to see how people could encrypt it from the command line. If I recommend that people would remember my name for the eternity in a bad way. Another insane idea was to provide encoders for GPG. The simplest idea, I think, would be provide code for people encrypt their passphrase and certificate, instead of trust in some software.
- aerogear-unifiedpush-java-client
No problem to implement it.
- aerogear-simplepush-java-client
No problem to implement it.
- aerogear-simplepush-node-client
Not so easy, but they do OpenSSL behind the scenes
- aerogear-unifiedpush-nodejs-client
Not so easy, but they do OpenSSL behind the scenes
So, what do you think? Yay/Nay? I would never use that?
The goal is to provide secure alternatives to developers, but if the whole process will turn into a pain, I won’t move forward.
--
abstractj
11 years
Keycloak Alpha-4 (was: Re: [keycloak-dev] Alpha-3 issues)
by Matthias Wessendorf
On Thu, Mar 13, 2014 at 4:12 PM, Bill Burke <bburke(a)redhat.com> wrote:
> I was able to reproduce and fix it. alpha 4 release incoming.
>
>
Besides the previous NPE on user creation:
I can confirm the alpha-4 works also fine w/ the UPS branch that aims to
integrate Keycloak!
Thanks for the quick reply!
Cheers!
Matthias
>
> On 3/13/2014 11:00 AM, Matthias Wessendorf wrote:
>
>> just saw
>>
>> https://github.com/keycloak/keycloak/pull/294
>>
>>
>> let me build it locally and give it a quick run here
>>
>>
>> -M
>>
>>
>> On Thu, Mar 13, 2014 at 3:56 PM, Matthias Wessendorf <matzew(a)apache.org
>> <mailto:matzew@apache.org>> wrote:
>>
>> damn! email - how does it work?
>>
>> Sorry, but by accident I did not reply to the list :)
>>
>> * cache clearing did help;
>>
>> * Regarding the NPE Bill replied "Ok, I'll take a look and push
>> another release. Probably just need a null check."
>>
>>
>> -M
>>
>> On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf
>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>>
>>
>>
>>
>> On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>>
>>
>> On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>> > Hello,
>> >
>> > when deploying the |deployments| folder of the
>> > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the
>> following/WARN/:
>> >
>> > |10:02:18,449 WARN [org.jboss.as.ee
>> <http://org.jboss.as.ee> <http://org.jboss.as.ee>] (MSC
>>
>> service thread 1-9) JBAS011006: Not installing optional
>> component
>> org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>> due to exception:
>> org.jboss.as.server.deployment.DeploymentUnitProcessingExcept
>> ion:
>> JBAS011054: Could not find default constructor for class
>> org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>> > at
>> org.jboss.as.ee.component.ComponentDescription$
>> DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>> > at
>> org.jboss.as.ee.component.deployers.
>> EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor
>> .java:81)
>> > at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.
>> start(DeploymentUnitPhaseService.java:113)
>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>> > at
>> org.jboss.msc.service.ServiceControllerImpl$
>> StartTask.startService(ServiceControllerImpl.java:1811)
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>> <http://1.0.2.GA>]
>> > at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
>> ServiceControllerImpl.java:1746)
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>> <http://1.0.2.GA>]
>> > at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1110)
>> [rt.jar:1.7.0_09]
>> > at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:603)
>> [rt.jar:1.7.0_09]
>> > at java.lang.Thread.run(Thread.java:722)
>> [rt.jar:1.7.0_09]
>> >
>>
>> Haven't figured out the above ^. I assume you are running
>> on EAP/AS7?
>>
>>
>>
>> Correct - JBoss AS 7.1.1-Final
>>
>>
>> |
>> >
>> > Now, login (admin:admin) and the reset flow works fine.
>> After creating a
>> > REALM, I am on the Tab (of the new realm), but there I
>> notice a few
>> > "Page not found..." messages for these links:
>> >
>>
>> Try clearing your browser cache and trying everything again.
>>
>>
>>
>> great! now I could create some roles and set default roles.
>>
>>
>> However, the NPE on user creation is still present:
>>
>>
>>
>> Caused by: java.lang.NullPointerException
>>
>> at
>> org.keycloak.services.resources.admin.UsersResource.
>> updateUserFromRep(UsersResource.java:123)
>> [keycloak-services-1.0-alpha-3.jar:]
>>
>> at
>> org.keycloak.services.resources.admin.UsersResource.
>> createUser(UsersResource.java:106)
>> [keycloak-services-1.0-alpha-3.jar:]
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.7.0_09]
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>> [rt.jar:1.7.0_09]
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.7.0_09]
>>
>> at java.lang.reflect.Method.invoke(Method.java:601)
>> [rt.jar:1.7.0_09]
>>
>> at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(
>> MethodInjectorImpl.java:137)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
>> ResourceMethodInvoker.java:280)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(
>> ResourceMethodInvoker.java:234)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:103)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(
>> SynchronousDispatcher.java:356)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> ... 22 more
>>
>>
>>
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
cordova push plugin simplification
by Erik Jan de Wit
Hi,
As you may have experienced or seen the cordova push plugin is not always simple to get started with, there are still some things that are platform specific even though compared to the ‘original’ it has improved there is room for improvement. Here are some suggestions to make it even simpler:
Right now the API looks like this:
var pushConfig = {
// senderID is only used in the Android/GCM case
senderID: "<senderID e.g Google Project ID only for android>",
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
}
//badge and sound are iOS specific, and ignored on Android
push.register(successHandler, errorHandler, {"badge": "true", "sound": "true",
"ecb": "onNotification", pushConfig: pushConfig});
Suggestion number one, is to remove the successHandler and use that as the callback for notifications:
push.register(onNotification, errorHandler, {"badge": "true", "sound": "true", pushConfig: pushConfig});
Now the Javascript can verify that the callback is a function because it’s no longer a string and the need for a separate successHandler is overrated as you will either get messages or your errorHandler gets invoked.
For iOS we have these badge and sound flags we could we get rid of those as well? When you don’t want a badge then just don’t send it in the message!? Then the pushConfig can be inlined making it look like this:
push.register(onNotification, errorHandler, {
// senderID is only used in the Android/GCM case
senderID: "<senderID e.g Google Project ID only for android>",
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Till now all these changes can be made on the plugin, but we could take it even further. Two things that are still platform dependent the senderId and the variantID/secret. Now senderId is ‘known’ by UPS so why do we need to specify it here? We could make senderId part of the response when registering a device on UPS then the client doesn’t need to specify it and all configuration is in one place.
That leaves variantID/secret and that is the boldest proposal. How about we make it possible to register for an application instead for a specific variant? Then based on the meta information (deviceType, operatingSystem and osVersion) we choose the right variant.
If we do all of the above there will be no platform specific code at all and the final script could look as simple as this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
applicationID: "<applicationID e.g. 1234456-234320>",
secret: "<secret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Push notifications in one statement for all devices :)
WDYT
Erik Jan
11 years
AeroGear Crypto Java 0.1.3 Staged
by Bruno Oliveira
Good morning everyone, AG Crypto Java was staged under the following maven profile: https://repository.jboss.org/nexus/content/repositories/jboss_re...
I’m planning to release it on Friday morning (14/03)
Changelog:
* 17b9787 (upstream-abstractj/keypair-encoding, keypair-encoding) Explicit imports, instead of wildcards
* 7e595da Accept a raw key pair. For scenarios where the public key is transmitted over the wire
a34b746 Test refactoring
* 880be04 Add support on cryptobox to accept a public key for encryption
* a2c39ff Testing vectors for public key encryption
* 4421bc3 (upstream-abstractj/pom, pom) Change the scope for bouncycastle
* f190d64 (upstream-abstractj/refactor, refactor) Accept KeyPair as argument
* 832127a (AGSEC-147) Hashing support for SHA-256 and SHA-512
--
abstractj
11 years
