aerogear-js Mozilla's Persona authentication adapter
by Apostolos Emmanouilidis
hello,
while looking at AGJS-122 and the possibility to add an authentication adapter which is based on Mozilla's Persona sign-in system, I was thinking of the following API:
// Construct an AeroGear.Authentication.adapters.Persona
var persona = AeroGear.Auth({
name: 'persona',
type: 'Persona',
settings: {
verificationEndpoint: "http://127.0.0.1:3000/verify"
}
}).modules.persona;
// use login to initiate the Mozilla's Persona authentication procedure. login enables the BrowserID and generates a signed assertion which contains the user's email address
// on assertion generation call the verification service
persona.login({
onAssertion: function ( assertion ) {
// the verification API receives the assertion and the audience (our website URL) as parameters
// for security reasons there must be an intermediate service between the client and the verification API. the reason for which we want the intermediate service
// is that we want to ensure that the audience parameter is not hacked. I was thinking that it is better to avoid adding the persona.verify call inside our adapter
// since this way we would force the user to create the intermediate service according our implementation. That's why the following line exists:
persona.verify( { assertion: assertion }, { success: onSuccessVerification, error: onFailedVerification } );
},
error: onLoginError
});
// logout
persona.logout( onLogout );
I have added a working example in: https://github.com/tolis-e/aerogear-js-persona-authentication-poc
and a first implementation sample: https://github.com/aerogear/aerogear-js/pull/100
In order you'd like to try the working example on Android emulator, change lines:
https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/ma...
and
https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/ma...
to use host 10.0.2.2
and open the http://10.0.2.2:3000/persona-test.html page on the Android browser
any thoughts, suggestions?
9 years, 2 months
Keycloak integration ideas
by Jay Balunas
Hi All,
Sorry all - book mode ;-)
We've had a couple of threads around keycloak integration (thanks Abstractj) and working together with them (both in our dev list and theirs). I had a meeting (dinner really) with Bill and talked about some possibilities and we're both excited to see what can happen.
I wanted to capture some of those thoughts here (as well as some that already started before), have some discussions, and more importantly talk about next steps (jira's) to get some of this in the pipeline. I'm sure this is not exhaustive either, so please add your own thoughts, brainstorming etc... (for example Cordova plugin perhaps?)
*In no particular order
A) AeroGear security integration
** Abstractj already posted and implemented some of these changes
** http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGe...
** What's left here? Is it plug-able? Does it need to be?
B) Crypto key management
** Server-side encryption key management for client crypto
** Abstractj had some discussions here
*** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html
*** Where does that stand?
** Do we need our own impl as well?
C) UnifiedPush server integration
** User management, Auth*
** Do we have our own basic impl for quickstart experience?
** See below for possible combined cartridge options
D) Cross-project examples, tutorials, docs, etc...
** TBD
KeyCloak has some things they need as well, that we could work together on. I'm sure the KeyCloak team could add more here :-)
Z) Device support
** We need it, they need, and others need it
** Bill would like us to help them (and us at the same time) with this.
Y) OpenShift Cartridge for KeyCloak
** I know this is already on their roadmap
** The work Farah and others has already done, could be very helpful to them
** We should also discuss the possibility of a joint cartridge
*** Could be really compelling, especially if you add in device, client key, and push support with native SDKs & examples
*** Would also want separate cartridges as well imo
X) Client SDK support
** We have client SDKs & could help with their dev (either as part of AeroGear or KeyCloak perhaps)
** Primarily for iOS & Android, but would also want see where JS & Cordova fit.
You start putting all of this together and there is a great set of functionality that really compliments each other well. After we discuss for a while, I'd like to find owners for the various items to help make progress on these. Abstractj is awesome, but not sure he can do it all ;-)
-Jay
PS: I'll post an email to the keycloak-dev list as well pointing to this thread on our list.
9 years, 2 months
[UPS] User Management - open items / following up
by Sebastien Blanc
Hi,
Since the User Management PR has been submitted [1] there has been of a lot
of useful and interesting feedback, thanks Matzew and Abstractj for that.
Some valid concerns has been raised, in particular 2 of them that I would
like to expose here and to discuss to see how we can deal witth them for
the 0.10.0 release :
1.
Currently the password register/reset link that is generated is persisted.
This is a point of concern[2]. The fact is that with the current flow, we
can not go against that:
- An admin create an user, a link is generated.
- The admin send this link to the new user.
- The user browse to link -> at this moment we need to be able to retrieve
the stored link to check for its validity.
Some points :
- The token/register link is presisted without any relation with the newly
created user, so an hacker could not make a connection between the 2.
- The new created user, as long he has not registered through the link,
can not log into the system as he has no password, as Bruno suggested me to
do on the ML.
How shall we deal with that for 0.10.0 ? We can improve in 0.11.0 and also
keeping in mind that keycloak could come into the party quite soon.
2.
Currently, to generate the register link, we use a private key. This key is
located in the project[3]. This should not be in the github project as
pointed by Bruno [4] which make totally sense. I will remove the private
key from the repo and add instructions to tell how and where to put your
private key.
But I don't know how to deal for the UPS cartdridge, since we ship a war,
the private key will be missing. Any ideas input on that is welcome.
For 0.10.0, we could just ship a war containing a private key and add a
warning and maybe add instruction on how to clone the app locally, change
the key and push again (which is not really user friendly when you expect
to have a cartdridge that "just work").
Notice that there is ticket to be able to manage your private key from the
Admin console[5]
Again, in the future, keycloak could be used also to manage the keys.
Besides that, the current PR, in terms of functionnalities works : you can
create and manage users like specified in the specs.
So for the (very soon) 0.10.0 release how shall we deal with these concerns
?
Sebi
[1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118
[2]
https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussi...
[3]
https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_lin...
[4]
https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussi...
[5] https://issues.jboss.org/browse/AGPUSH-518
9 years, 2 months
simple Java sync server
by Erik Jan de Wit
Hi,
Made a very simple Java version (based on hibernate) of the sync server. It doesn’t merge so any change in a entity that is old will give a merge conflict. It uses the same ‘protocol’ as couch so WDYT?
Cheers,
Erik Jan
https://github.com/edewit/sync-server
9 years, 2 months
Website restructure
by Hylke Bons
Hey everyone,
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
1. Naming
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
2. Documentation
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
AeroGear API.
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
Missing pieces:
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
Thanks,
Hylke
9 years, 2 months
