+1, you nailed it
On Mon, Aug 24, 2015 at 3:19 PM, Summers Pittman <supittma(a)redhat.com>
So abstractj, corinnekrych, edewit, and I spoke this morning about
SAML support to the AeroGear client libraries. This lead to a few
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
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
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
What do you guys think?
PS Stay tuned for links to JIRAs
aerogear-dev mailing list
"The measure of a man is what he does with power" - Plato
Volenti Nihil Difficile