[aerogear-dev] AeroGear Security and friends deprecation

[Bruno Oliveira]

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

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

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