<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 3:36 PM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">&gt; &gt; On March 25, 2014 at 5:51:46 AM, Matthias Wessendorf (<a href="mailto:matzew@apache.org">matzew@apache.org</a>)&nbsp;<br>

&gt; &gt; &gt;&nbsp;<br>
</div><div class="">&gt; &gt; &gt; One thing that just came to mind is the implications for the clients.&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; It shouldn&#39;t exist once we are server agnostic&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt;&nbsp;<br>
&gt;&nbsp;<br>
&gt; you mean no implications on the client, right ?&nbsp;<br>
<br>
</div>Yes!&nbsp;<br>
<div class="im HOEnZb"><br>
&gt; &gt; &gt;&nbsp;<br>
&gt; &gt; &gt; Now, I am wondering, what does the deprecation of the java libraries&nbsp;<br>
&gt; &gt; &gt; mean for the client offerings? For instance, once we did port&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; I can be dead wrong, but this deprecation doesn&#39;t mean to much to me. Why?&nbsp;<br>
&gt; &gt; AG Security is just few classes to fill in the gaps from PicketLink in the&nbsp;<br>
&gt; &gt; past.&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; Our offerings should not be tied to the server side, at least for&nbsp;<br>
&gt; &gt; authentication.&nbsp;<br>
&gt;&nbsp;<br>
&gt;&nbsp;<br>
&gt; yeah - I am not sure that is really the case - I can be wrong; But I think&nbsp;<br>
&gt; that the &quot;AGRestAuthentication.m&quot; is a bit tied to AG Security&#39;s PicketLink&nbsp;<br>
&gt; Module&nbsp;<br>
<br>
</div><div class="im HOEnZb">If that is happening, we must fix this.&nbsp;<br>
<br>
&gt;&nbsp;<br>
</div><div class="im HOEnZb">&gt; &gt; How could I authenticate with AeroGear and Node.js?&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt;&nbsp;<br>
&gt; I don&#39;t know. I *think* IF the endpoints would actually follow this spec,&nbsp;<br>
&gt; it would work:&nbsp;<br>
&gt; <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>&nbsp;<br>
<br>
</div><div class="im HOEnZb">Think about people interacting with legacies, they can&rsquo;t just say &ldquo;hey, would you mind to change your endpoint?&rdquo;. For this reason,&nbsp;<br>
we should have the flexibility to specify endpoints + parameters (<a href="https://github.com/aerogear/aerogear-android-cookbook/blob/master/src/org/jboss/aerogear/cookbook/authentication/HowToUseAuthentication.java#L70" target="_blank">https://github.com/aerogear/aerogear-android-cookbook/blob/master/src/org/jboss/aerogear/cookbook/authentication/HowToUseAuthentication.java#L70</a>).&nbsp;<br>

<br>
It shouldn&#39;t matter if the endpoint is &ldquo;login&rdquo; or &ldquo;enroll&rdquo;. Or parameters are &ldquo;login&rdquo; or &ldquo;username&rdquo;.&nbsp;<br></div></blockquote><div><br></div><div>right - it&#39;s already flexible :)&nbsp;</div><div><br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb">
<br>
&gt;&nbsp;<br>
&gt;&nbsp;<br>
</div><div class="im HOEnZb">&gt; But my hope is that, in the future, we only have OAuth2 and the &#39;legacy&#39;&nbsp;<br>
&gt; bits like BASIC/DIGEST. Great thing here: they are actually (well) defined&nbsp;<br>
&gt; protocols.&nbsp;<br>
<br>
</div><div class="im HOEnZb">That&rsquo;s pretty much what we do today, I guess.&nbsp;<br>
<br>
</div><div class="im HOEnZb">&gt; &gt; &gt; the endpoints (for instance on AeroDoc) to vanilla PicketLink,&nbsp;<br>
&gt; &gt; &gt; should this iOS class/module just function like before? Or does&nbsp;<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; Yes, they just need to be adapted and have AG Security removed. Today, we&nbsp;<br>
&gt; &gt; don&#39;t need anymore 2 jars only for login/logout. Just stick with Apache&nbsp;<br>
&gt; &gt; Shiro, PicketLink&nbsp;<br>
&gt;&nbsp;<br>
&gt;&nbsp;<br>
&gt; So, yeah if the endpoints ported to plain PL/Shiro/etc they would have to&nbsp;<br>
&gt; follow this spec, right ?&nbsp;<br>
&gt; <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>&nbsp;<br>
<br>
</div><div class="im HOEnZb">For examples, yes. But, we shouldn&rsquo;t me tied to this. What would happen with the client if I want to name my endpoints with: &ldquo;/register&rdquo;, &ldquo;/signin&rdquo; and &ldquo;/signout&rdquo; ? &nbsp;<br>
<br>
See: <a href="https://github.com/aerogear/aerogear-js/blob/master/tests/unit/authentication/authentication-rest.js#L13" target="_blank">https://github.com/aerogear/aerogear-js/blob/master/tests/unit/authentication/authentication-rest.js#L13</a>&nbsp;<br>
</div></blockquote><div><br></div><div><br></div><div>yep - that is present as well.</div><div><br></div><div><br></div><div><br></div><div>-Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><div>&nbsp;</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
</div><div class="im HOEnZb">&gt; yeah - I picked iOS only because I know that code a bit better than Android&nbsp;<br>
&gt; or JS ;-)&nbsp;<br>
<br>
</div><div class="HOEnZb"><div class="h5">I know, that new update for iOS 7.1 called &ldquo;drain my battery&rdquo; is awesome.<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>