<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 12:04 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ahoy, answers inline<br>
<br>
--<br>
abstractj<br>
<div class=""><br>
On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (<a href="mailto:matzew@apache.org">matzew@apache.org</a>) wrote:<br>
> > Hello again!<br>
><br>
> One thing that just came to mind is the implications for the clients. <br>
<br>
</div>It shouldn’t exist once we are server agnostic<br></blockquote><div><br></div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">you mean no implications on the client, right ? </span></div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
><br>
> Today the client libs are supporting "AeroGear Security", for<br>
> cases like the RESTful login.<br>
<br>
</div>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 <a href="https://github.com/abstractj/example-jaxrs-shiro" target="_blank">https://github.com/abstractj/example-jaxrs-shiro</a> (Plain Shiro with RESTful endpoints) <br>
<div class=""><br>
><br>
> For example, taking the iOS library:<br>
> <a href="https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/security/AGRestAuthentication.m" target="_blank">https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/security/AGRestAuthentication.m</a><br>
><br>
> This class somewhat expects an endpoint, that under the covers<br>
> uses AeroGear Security-PicketLink JAR. The AGIOS-35 ticket<br>
> is a good example of how client had to be changed due to updates<br>
> on the used version of PicketLink.<br>
<br>
</div>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.<br>
<br>
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.<br>
</blockquote><div><br></div><div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">yep, it's pretty much aligned to that. I think same is true for other client offerings as well (not really sure)</div>
<div class="im" style="font-family:arial,sans-serif;font-size:13px"></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
For basic and digest authentication, both must follow the protocol specification.<br></blockquote><div><br></div><div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">right - that's way simpler, as we have an actual protocol there (similar to OAuth2)</div>
<div class="im" style="font-family:arial,sans-serif;font-size:13px"></div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
><br>
> Now, I am wondering, what does the deprecation of the java libraries<br>
> mean for the client offerings? For instance, once we did port <br>
<br>
</div>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.<br>
<br>
Our offerings should not be tied to the server side, at least for authentication. </blockquote><div><br></div><div><br></div><div>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<br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">How could I authenticate with AeroGear and Node.js?<br>
</blockquote><div><br></div><div><div><br></div><div class="im"><div style="font-family:arial,sans-serif;font-size:13px"><div style="color:rgb(34,34,34)">I don't know. I *think* IF the endpoints would actually follow this spec, it would work:</div>
<div style="color:rgb(34,34,34)"><a href="http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security" target="_blank">http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security</a></div><div style="color:rgb(34,34,34)">
<br></div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">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.<br>
</div><div class="im"> </div><div class="im"><br></div></div></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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. <br>
<div class=""><br>
<br>
<br>
> the endpoints (for instance on AeroDoc) to vanilla PicketLink,<br>
> should this iOS class/module just function like before? Or does <br>
<br>
</div>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</blockquote><div><br></div><div><div><br></div><div>
<br></div><div>So, yeah if the endpoints ported to plain PL/Shiro/etc they would have to follow this spec, right ? </div><div><a href="http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security" target="_blank">http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security</a><br>
</div><div class="im"><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
or Keycloak and that’s all.<br>
<div class=""><br>
> it even make sense to keep that functionality? Or, instead of<br>
> on the "core" module (speaking iOS), would it make sense to move<br>
> it into a different/separate project ?<br>
<br>
</div>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.<br>
<br>
It doesn’t matter if is iOS, Android or JS, every project was supposed to be server agnostic. (Is just my opinion)<br></blockquote><div><br></div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">yeah - I picked iOS only because I know that code a bit better than Android or JS ;-)</span><br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
><br>
> Greetings,<br>
> Matthias<br>
<br>
><br>
> [AGIOS-35] <a href="https://issues.jboss.org/browse/AGIOS-35" target="_blank">https://issues.jboss.org/browse/AGIOS-35</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>