[aerogear-dev] AeroGear Security and friends deprecation

[Matthias Wessendorf]

On Tue, Mar 25, 2014 at 12:04 PM, Bruno Oliveira <bruno at abstractj.org>wrote:

> Ahoy, answers inline
>
> --
> abstractj
>
> On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (matzew at 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/security/AGRestAuthentication.m
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140325/7d7d7520/attachment-0001.html