[aerogear-dev] AeroGear Security and friends deprecation

[Matthias Wessendorf]

On Tue, Mar 25, 2014 at 3:36 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

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

right - it's already flexible :)



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


yep - that is present as well.



-Matthias






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



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140325/4f9bcdd4/attachment.html