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