[aerogear-dev] AeroGear Security and friends deprecation

[Bruno Oliveira]

> > On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (matzew at 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/jboss/aerogear/cookbook/authentication/HowToUseAuthentication.java#L70). 

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/authentication/authentication-rest.js#L13 

> 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.