1:21 p.m.
Good morning everyone, today I would like to announce the deprecation of the following
projects:
- AeroGear Security
- AeroGear Security PicketLink
- AeroGear Security Hawk
- AeroGear Security Shiro
Please see: https://issues.jboss.org/browse/AGSEC-179. This decision didn’t come from
nowhere. We just had few classes, created because we didn’t have a final solution for
security on the server side. Today we have Keycloak and Picketlink to replace AeroGear
Security and we are not abandoning security on the server side, just joining our efforts
with Keycloak.
The following projects will be immediately affected:
- https://github.com/aerogear/aerogear-jaxrs-demo
- https://github.com/aerogear/aerogear-unifiedpush-server
- https://github.com/aerogear/aerogear-integration-tests-server
- https://github.com/aerogear/aerogear-aerodoc-backend
I will be working to migrate the codebase. If you this change might affect you, please
raise your hand.
I’m doing it for the best.
--
abstractj
1:52 p.m.
Hello there,
and thanks for the heads up!
On Mon, Mar 24, 2014 at 7:21 PM, Bruno Oliveira <bruno(a)abstractj.com> wrote:
Good morning everyone, today I would like to announce the deprecation
of
the following projects:
- AeroGear Security
- AeroGear Security PicketLink
- AeroGear Security Hawk
- AeroGear Security Shiro
Please see: https://issues.jboss.org/browse/AGSEC-179. This decision
didn't come from nowhere. We just had few classes, created because we
didn't have a final solution for security on the server side. Today we have
Keycloak and Picketlink to replace AeroGear Security and we are not
abandoning security on the server side, just joining our efforts with
Keycloak.
The following projects will be immediately affected:
- https://github.com/aerogear/aerogear-jaxrs-demo
- https://github.com/aerogear/aerogear-unifiedpush-server
- https://github.com/aerogear/aerogear-integration-tests-server
- https://github.com/aerogear/aerogear-aerodoc-backend
I will be working to migrate the codebase.
awesome!
One note on the UPS:
We have this branch (already updated on the latest alpha-4):
https://github.com/aerogear/aerogear-unifiedpush-server/tree/Keycloak_aft...
I am currently looking for a slightly better integration, instead of
pointing to a separate deployed WAR file:
- e.g. bundle KC libs and realm-setup inside our WAR; Or providing an EAR
file (UPS.war + KC.war), etc.
This is currently in on 'research' :-) Hopefully, in very soon this branch
will be merged down to master, celebrated w/ an 0.11.0 release :-)
If you this change might affect you, please raise your hand.
I'm doing it for the best.
+1 great move!
-M
--
abstractj
_______________________________________________
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
3:27 a.m.
Make sense !
I can of course help for the migration (especially for aerodoc).
On Mon, Mar 24, 2014 at 7:52 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Hello there,
and thanks for the heads up!
On Mon, Mar 24, 2014 at 7:21 PM, Bruno Oliveira <bruno(a)abstractj.com>wrote:
> Good morning everyone, today I would like to announce the deprecation of
> the following projects:
>
> - AeroGear Security
> - AeroGear Security PicketLink
> - AeroGear Security Hawk
> - AeroGear Security Shiro
>
> Please see: https://issues.jboss.org/browse/AGSEC-179. This decision
> didn't come from nowhere. We just had few classes, created because we
> didn't have a final solution for security on the server side. Today we have
> Keycloak and Picketlink to replace AeroGear Security and we are not
> abandoning security on the server side, just joining our efforts with
> Keycloak.
>
> The following projects will be immediately affected:
>
> - https://github.com/aerogear/aerogear-jaxrs-demo
> - https://github.com/aerogear/aerogear-unifiedpush-server
> - https://github.com/aerogear/aerogear-integration-tests-server
> - https://github.com/aerogear/aerogear-aerodoc-backend
>
> I will be working to migrate the codebase.
awesome!
One note on the UPS:
We have this branch (already updated on the latest alpha-4):
https://github.com/aerogear/aerogear-unifiedpush-server/tree/Keycloak_aft...
I am currently looking for a slightly better integration, instead of
pointing to a separate deployed WAR file:
- e.g. bundle KC libs and realm-setup inside our WAR; Or providing an EAR
file (UPS.war + KC.war), etc.
This is currently in on 'research' :-) Hopefully, in very soon this branch
will be merged down to master, celebrated w/ an 0.11.0 release :-)
> If you this change might affect you, please raise your hand.
>
> I'm doing it for the best.
>
+1 great move!
-M
>
>
> --
> abstractj
>
> _______________________________________________
> 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
3:51 a.m.
Hello again!
One thing that just came to mind is the implications for the clients.
Today the client libs are supporting "AeroGear Security", for cases like
the RESTful login.
For example, taking the iOS library:
https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/securit...
This class somewhat expects an endpoint, that under the covers uses
AeroGear Security-PicketLink JAR. The AGIOS-35 ticket is a good example of
how client had to be changed due to updates on the used version of
PicketLink.
Now, I am wondering, what does the deprecation of the java libraries mean
for the client offerings? For instance, once we did port the endpoints (for
instance on AeroDoc) to vanilla PicketLink, should this iOS class/module
just function like before? Or does it even make sense to keep that
functionality? Or, instead of on the "core" module (speaking iOS), would
it make sense to move it into a different/separate project ?
Greetings,
Matthias
[AGIOS-35] https://issues.jboss.org/browse/AGIOS-35
On Mon, Mar 24, 2014 at 7:21 PM, Bruno Oliveira <bruno(a)abstractj.com> wrote:
Good morning everyone, today I would like to announce the deprecation
of
the following projects:
- AeroGear Security
- AeroGear Security PicketLink
- AeroGear Security Hawk
- AeroGear Security Shiro
Please see: https://issues.jboss.org/browse/AGSEC-179. This decision
didn't come from nowhere. We just had few classes, created because we
didn't have a final solution for security on the server side. Today we have
Keycloak and Picketlink to replace AeroGear Security and we are not
abandoning security on the server side, just joining our efforts with
Keycloak.
The following projects will be immediately affected:
- https://github.com/aerogear/aerogear-jaxrs-demo
- https://github.com/aerogear/aerogear-unifiedpush-server
- https://github.com/aerogear/aerogear-integration-tests-server
- https://github.com/aerogear/aerogear-aerodoc-backend
I will be working to migrate the codebase. If you this change might affect
you, please raise your hand.
I'm doing it for the best.
--
abstractj
_______________________________________________
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
6:04 a.m.
Ahoy, answers inline
--
abstractj
On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (matzew(a)apache.org) wrote:
> Hello again!
One thing that just came to mind is the implications for the clients.
It shouldn’t exist once we are server agnostic
Today the client libs are supporting "AeroGear Security", for
cases like the RESTful login.
I would say that’s a wrong assumption. Our client libraries rely on RESTful endpoints, not
AG Security. For example, I could run AG Android against
https://github.com/abstractj/example-jaxrs-shiro (Plain Shiro with RESTful endpoints)
For example, taking the iOS library:
https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/securit...
This class somewhat expects an endpoint, that under the covers
uses AeroGear Security-PicketLink JAR. The AGIOS-35 ticket
is a good example of how client had to be changed due to updates
on the used version of PicketLink.
If we’ve been doing it, that’s wrong. Because you tie the client with the server. I think
the correct would be the opposite or some balance.
For plain database authentication, the server could adapt its endpoints for what AeroGear
expects. Or, the client should allow our dev to configure parameters. AGIOS-35 seems to be
hard-coded parameters, which ties the client with the server.
For basic and digest authentication, both must follow the protocol specification.
Now, I am wondering, what does the deprecation of the java libraries
mean for the client offerings? For instance, once we did port
I can be dead wrong, but this deprecation doesn’t mean to much to me. Why? AG Security is
just few classes to fill in the gaps from PicketLink in the past.
Our offerings should not be tied to the server side, at least for authentication. How
could I authenticate with AeroGear and Node.js?
In the worst case scenario, AG Security still exists. But we will no longer support it, so
people can fork, copy and whatever they want.
the endpoints (for instance on AeroDoc) to vanilla PicketLink,
should this iOS class/module just function like before? Or does
Yes, they just need to be adapted and have AG Security removed. Today, we don’t need
anymore 2 jars only for login/logout. Just stick with Apache Shiro, PicketLink or Keycloak
and that’s all.
it even make sense to keep that functionality? Or, instead of
on the "core" module (speaking iOS), would it make sense to move
it into a different/separate project ?
I don’t think so, our focus relies on the client side and offerings for mobile on the
server side. Security on the server is Keycloak and Picketlink responsibility, and yes, we
will help on it.
It doesn’t matter if is iOS, Android or JS, every project was supposed to be server
agnostic. (Is just my opinion)
Greetings,
Matthias
[AGIOS-35] https://issues.jboss.org/browse/AGIOS-35
7:37 a.m.
On Tue, Mar 25, 2014 at 12:04 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
Ahoy, answers inline
--
abstractj
On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (matzew(a)apache.org)
wrote:
> > Hello again!
>
> One thing that just came to mind is the implications for the clients.
It shouldn't exist once we are server agnostic
you mean no implications on the client, right ?
>
> Today the client libs are supporting "AeroGear Security", for
> cases like the RESTful login.
I would say that's a wrong assumption. Our client libraries rely on
RESTful endpoints, not AG Security. For example, I could run AG Android
against https://github.com/abstractj/example-jaxrs-shiro (Plain Shiro
with RESTful endpoints)
>
> For example, taking the iOS library:
>
https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/securit...
>
> This class somewhat expects an endpoint, that under the covers
> uses AeroGear Security-PicketLink JAR. The AGIOS-35 ticket
> is a good example of how client had to be changed due to updates
> on the used version of PicketLink.
If we've been doing it, that's wrong. Because you tie the client with the
server. I think the correct would be the opposite or some balance.
For plain database authentication, the server could adapt its endpoints
for what AeroGear expects. Or, the client should allow our dev to configure
parameters. AGIOS-35 seems to be hard-coded parameters, which ties the
client with the server.
yep, it's pretty much aligned to that. I think same is true for other
client offerings as well (not really sure)
For basic and digest authentication, both must follow the protocol
specification.
right - that's way simpler, as we have an actual protocol there (similar to
OAuth2)
>
> Now, I am wondering, what does the deprecation of the java libraries
> mean for the client offerings? For instance, once we did port
I can be dead wrong, but this deprecation doesn't mean to much to me. Why?
AG Security is just few classes to fill in the gaps from PicketLink in the
past.
Our offerings should not be tied to the server side, at least for
authentication.
yeah - I am not sure that is really the case - I can be wrong; But I think
that the "AGRestAuthentication.m" is a bit tied to AG Security's PicketLink
Module
How could I authenticate with AeroGear and Node.js?
I don't know. I *think* IF the endpoints would actually follow this spec,
it would work:
http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
But my hope is that, in the future, we only have OAuth2 and the 'legacy'
bits like BASIC/DIGEST. Great thing here: they are actually (well) defined
protocols.
In the worst case scenario, AG Security still exists. But we will no
longer support it, so people can fork, copy and whatever they want.
> the endpoints (for instance on AeroDoc) to vanilla PicketLink,
> should this iOS class/module just function like before? Or does
Yes, they just need to be adapted and have AG Security removed. Today, we
don't need anymore 2 jars only for login/logout. Just stick with Apache
Shiro, PicketLink
So, yeah if the endpoints ported to plain PL/Shiro/etc they would have to
follow this spec, right ?
http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
or Keycloak and that's all.
> it even make sense to keep that functionality? Or, instead of
> on the "core" module (speaking iOS), would it make sense to move
> it into a different/separate project ?
I don't think so, our focus relies on the client side and offerings for
mobile on the server side. Security on the server is Keycloak and
Picketlink responsibility, and yes, we will help on it.
It doesn't matter if is iOS, Android or JS, every project was supposed to
be server agnostic. (Is just my opinion)
yeah - I picked iOS only because I know that code a bit better than Android
or JS ;-)
>
> Greetings,
> Matthias
>
> [AGIOS-35] https://issues.jboss.org/browse/AGIOS-35
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:36 a.m.
> On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf
(matzew(a)apache.org)
> >
> > One thing that just came to mind is the implications for the clients.
>
> It shouldn't exist once we are server agnostic
>
you mean no implications on the client, right ?
Yes!
> >
> > Now, I am wondering, what does the deprecation of the java libraries
> > mean for the client offerings? For instance, once we did port
>
> I can be dead wrong, but this deprecation doesn't mean to much to me. Why?
> AG Security is just few classes to fill in the gaps from PicketLink in the
> past.
>
> Our offerings should not be tied to the server side, at least for
> authentication.
yeah - I am not sure that is really the case - I can be wrong; But I think
that the "AGRestAuthentication.m" is a bit tied to AG Security's
PicketLink
Module
If that is happening, we must fix this.
> How could I authenticate with AeroGear and Node.js?
>
I don't know. I *think* IF the endpoints would actually follow this spec,
it would work:
http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
Think about people interacting with legacies, they can’t just say “hey, would you mind to
change your endpoint?”. For this reason,
we should have the flexibility to specify endpoints + parameters
(https://github.com/aerogear/aerogear-android-cookbook/blob/master/src/org...
It shouldn't matter if the endpoint is “login” or “enroll”. Or parameters are “login”
or “username”.
But my hope is that, in the future, we only have OAuth2 and the 'legacy'
bits like BASIC/DIGEST. Great thing here: they are actually (well) defined
protocols.
That’s pretty much what we do today, I guess.
> > the endpoints (for instance on AeroDoc) to vanilla
PicketLink,
> > should this iOS class/module just function like before? Or does
>
> Yes, they just need to be adapted and have AG Security removed. Today, we
> don't need anymore 2 jars only for login/logout. Just stick with Apache
> Shiro, PicketLink
So, yeah if the endpoints ported to plain PL/Shiro/etc they would have to
follow this spec, right ?
http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
For examples, yes. But, we shouldn’t me tied to this. What would happen with the client if
I want to name my endpoints with: “/register”, “/signin” and “/signout” ?
See:
https://github.com/aerogear/aerogear-js/blob/master/tests/unit/authentica...
yeah - I picked iOS only because I know that code a bit better than
Android
or JS ;-)
I know, that new update for iOS 7.1 called “drain my battery” is awesome.
10:03 a.m.
On Tue, Mar 25, 2014 at 3:36 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> > On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (
matzew(a)apache.org)
> > >
> > > One thing that just came to mind is the implications for the
clients.
> >
> > It shouldn't exist once we are server agnostic
> >
>
>
> you mean no implications on the client, right ?
Yes!
> > >
> > > Now, I am wondering, what does the deprecation of the java libraries
> > > mean for the client offerings? For instance, once we did port
> >
> > I can be dead wrong, but this deprecation doesn't mean to much to me.
Why?
> > AG Security is just few classes to fill in the gaps from PicketLink in
the
> > past.
> >
> > Our offerings should not be tied to the server side, at least for
> > authentication.
>
>
> yeah - I am not sure that is really the case - I can be wrong; But I
think
> that the "AGRestAuthentication.m" is a bit tied to AG Security's
PicketLink
> Module
If that is happening, we must fix this.
>
> > How could I authenticate with AeroGear and Node.js?
> >
>
> I don't know. I *think* IF the endpoints would actually follow this
spec,
> it would work:
> http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
Think about people interacting with legacies, they can't just say "hey,
would you mind to change your endpoint?". For this reason,
we should have the flexibility to specify endpoints + parameters (
https://github.com/aerogear/aerogear-android-cookbook/blob/master/src/org...
).
It shouldn't matter if the endpoint is "login" or "enroll". Or
parameters
are "login" or "username".
right - it's already flexible :)
>
>
> But my hope is that, in the future, we only have OAuth2 and the 'legacy'
> bits like BASIC/DIGEST. Great thing here: they are actually (well)
defined
> protocols.
That's pretty much what we do today, I guess.
> > > the endpoints (for instance on AeroDoc) to vanilla PicketLink,
> > > should this iOS class/module just function like before? Or does
> >
> > Yes, they just need to be adapted and have AG Security removed. Today,
we
> > don't need anymore 2 jars only for login/logout. Just stick with
Apache
> > Shiro, PicketLink
>
>
> So, yeah if the endpoints ported to plain PL/Shiro/etc they would have
to
> follow this spec, right ?
> http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
For examples, yes. But, we shouldn't me tied to this. What would happen
with the client if I want to name my endpoints with: "/register",
"/signin"
and "/signout" ?
See:
https://github.com/aerogear/aerogear-js/blob/master/tests/unit/authentica...
yep - that is present as well.
-Matthias
> yeah - I picked iOS only because I know that code a bit better than
Android
> or JS ;-)
I know, that new update for iOS 7.1 called "drain my battery" is awesome.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3685
days inactive
3686
days old
7 comments
4 participants
participants (4)
-
Bruno Oliveira -
Bruno Oliveira -
Matthias Wessendorf -
Sebastien Blanc