[aerogear-dev] SAML in Client libraries

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] SAML in Client libraries

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] SAML in Client libraries

Bruno Oliveira
+1, you nailed it

On Mon, Aug 24, 2015 at 3:19 PM, Summers Pittman <[hidden email]> wrote:
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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] SAML in Client libraries

danielbevenius
In reply to this post by Summers Pittman
+1 Sounds good

On 24 August 2015 at 20:19, Summers Pittman <[hidden email]> wrote:
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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] SAML in Client libraries

Matthias Wessendorf
In reply to this post by Summers Pittman


On Mon, Aug 24, 2015 at 8:19 PM, Summers Pittman <[hidden email]> wrote:
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.

+1000 on making this extra (ag-smal) libs!
 

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.

+1 

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.

awesome!
 

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?

sounds good to me, thanks for the updates!
 

Summers

PS Stay tuned for links to JIRAs

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev