SAML in Client libraries
by Summers Pittman
So abstractj, corinnekrych, edewit, and I spoke this morning about adding
SAML support to the AeroGear client libraries. This lead to a few
observations.
1 ) Mobile doesn't do SAML well (it is an OAuth 2 world)
2 ) SAML is VERY hard to set up and integrate with. (Multiple servers need
to exchange XML Metadata)
3 ) SAML was designed for hosted web applications, not for the RESTful
service web. (You need at least two servers to have an application use
SAML)
4 ) There aren't many widely used SAML libraries for mobile.
>From these observations we made the follow decisions.
1 ) We will extend the authorization libraries to include some kind of
solution for SAML. This will probably rely on a WebView and some form of
service broker to manage the authorization tokens. Passport-saml and
KeyCloak both seem to have abilities in this area and we will begin our
investigation there.
2) We will create a docker image which will be a turn key SAML server to
test integration with. Right now we are looking at using Shibboleth for
our service provider and identity provider. Keycloak will be used for
communicating with the AG-SAML libraries initially. Our goal, as always,
is to make our libraries as portable as possible.
3 ) We will provide some kind of server technology/integration plan to
serve as a template for adding mobile to existing SAML protected
applications. This will be at the least documentation on aerogear.org and
at the most a docker app based on shibboleth's SAML server.
4 ) We will build some demo applications to showcase integrating with a
SAML provider. Because SAML requires configuration on both the client and
ID servers our demo may have to be specific to services we can access or
host. SAML makes the workflows to enable OAuth support look like child's
play.
What do you guys think?
Summers
PS Stay tuned for links to JIRAs
10 years, 10 months
Staging of UPS 1.1.0-beta.4 (was: Re: Staging of UPS 1.1.0.Final)
by Matthias Wessendorf
Hello,
since we had a few issues found and serious changes on the underlying DB
schema (see Karel's mail), here is the staging of another beta:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
Idea is to afterwards have a stable time of a week, and get the
1.1.0.Final, finally out!
Any comments?
-Matthias
On Wed, Aug 12, 2015 at 8:52 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> Yes, I will discard the current staged release.
> Thanks Erik for reporting these issues.
>
>
>
> On Tue, Aug 11, 2015 at 10:39 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>> I think this is aldo worth to be included to 1.1.0.Final
>>
>>
>> On Tuesday, August 11, 2015, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>>
>>> I found these issues:
>>>
>>>
>>> 1. AGPUSH-1492 <https://issues.jboss.org/browse/AGPUSH-1492> Deleting
>>> an Application leaves installations
>>> 2.
>>> 1.
>>> 1. AGPUSH-1491 <https://issues.jboss.org/browse/AGPUSH-1491> Android
>>> doesn't show installations
>>>
>>>
>>> On Tue, Aug 11, 2015 at 1:06 PM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>> looking...
>>>>
>>>> On Fri, Aug 7, 2015 at 3:48 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hi team,
>>>>>
>>>>> I'm happy to announce that UPS 1.1.0 Final has been staged.
>>>>>
>>>>> Please test the staged release :
>>>>>
>>>>>
>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
>>>>>
>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>
>>>>> Sebi
>>>>>
>>>>> ps : the openshift update will follow
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Erik Jan
>>>
>>
>>
>> --
>> Sent from Gmail Mobile
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 10 months
Breaking changes in between UPS 1.1.0.Beta3 and 1.1.0.Final
by Karel Piwko
Hello All,
I'm really unhappy with number of breaking changes that has appeared in the
latest staged 1.1.0.Final - mostly these changes were related to massive DB
schema updates. I'd expect such changes to happen in Alpha phase and not in
between Beta3 and Final.
I understand that a lot of these changes have been driven by late inclusion
of migrator to 1.1 branch. That said, what is the plan with 1.1.0.Final?
Are you guys going to remove the changes or at least make sure they do not
impact users running Beta3? I've seen it has been de-staged and there have
been a few commits reverting DB changes back. Is there any estimate when
1.1.0.Final will be restaged?
QE plan is to make sure that migration from 1.0.3 is smooth, however we
also want migration from Beta3 to be smooth.
Many thanks,
Karel
10 years, 11 months
ng-cordova
by Erik Jan de Wit
Hi,
You might remember that we wanted to add the aerogear push plugin to the
ng-cordova project. So we create the PR, half a year ago and now 3 PR's [1]
later we have been added! Now getting started with cordova, angular and
push is super easy. Keep an eye out for the next release.
[1] https://github.com/driftyco/ng-cordova/pull/933
--
Cheers,
Erik Jan
10 years, 11 months
GCM Topics - split into two sender implementations?
by Lukáš Fryč
Hi guys,
/wrt the GCM Topics support PR
https://github.com/aerogear/aerogear-unifiedpush-server/pull/626
me and summersp have discussed how JMS should be used to route messages.
Current implementation loads tokens and conditionally sends either message
with registration IDs or topics.
There are two things yet to be solved:
- topics can be used up to 1 million registrations, otherwise you have
to fall back to enumerating registration IDs
- implementation with one sender (GCMPushNotificationSender) is
suboptimal
- the utilization of the topics can be increased by prioritizing
topic message sending first (covering multiple, potentially thousands
registrations)
- followed by sending registration IDs out
That's why I suggested to split implementation to two JMS queues talking to
two sender impls (e.g. GCMTopicSender and GCMRegistrationIdsSender).
- first we send out topic based messages (for efficiency)
- we collect those topics that fail and resend them for processing as
registration IDs (fail over)
- registration ids sending can start in parallel, but it can't end
until we sent out all topics
Additionally we get an ability to configure these two message routes
individually on the JMS level (better utilization, transact-ability, fail
over).
What do you think?
Cheers,
~ Lukas
10 years, 11 months
UPS Migrator error (1.1.0.Final)
by Oleg Matskiv
Hi,
can somebody who worked on UPS migrator recently, check if it deals with
recent database changes (e.g.
https://github.com/aerogear/aerogear-unifiedpush-server/commit/bbe1c0e80a...
).
I have run into error when running integration test with migrator run
(liquibase.exception.DatabaseException:
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Key column
'variantInformations_id' doesn't exist in table).
Thanks for any help.
--
Oleg Matskiv
Mobile QE Intern
omatskiv(a)redhat.com
10 years, 11 months
GCM Topics feature branch
by Summers Pittman
So it looks like the work for properly supporting topics is going to grow.
So far we have identified two areas for improvement already :
* lfryc and I met this afternoon and discussed how to handle topic
failures where calling back to registrationIds is appropriate. He has some
refactors he wants to make.
* Last night on the -users list a community member brought up some use
case we have to consider as well. Specifically around how `alias` and
`deviceType` interact with topics.
In the spirit of keeping the PRs manageable, I propose we create a feature
branches for topics in aerogear/aerogear-unifiedpush-server and
aerogear/aerogear-android-push.
Barring strong opinions against this, I will create these branches and move
my PRs appropriately.
10 years, 11 months
