[security-dev] [PLINK-400] - Stateless Nature of the Identity Bean

[Pedro Igor Silva]

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: security-dev at lists.jboss.org
> Sent: Tuesday, April 1, 2014 10:12:26 AM
> Subject: Re: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean
> 
> Pedro,
> 
> - how does the programmer figure out he is using the Identity bean in a
> stateless scope and other usage: session scope?

They can do that using a qualifier, an alternative or even a stereotype. Regarding the solution, it should be very clear which scope he is using.
The decision about supporting both scopes or not from the same application  is important to define what is the best solution.

> - will it add complexity to the internal implementation?

I don't think so. It should not bring any complexity to the implementation or API usage.

> 
> Regards,
> Anil
> 
> On 03/31/2014 09:57 PM, Pedro Igor Silva wrote:
> > Hi All,
> >
> >      Shane and I had a discussion today about PLINK-400 [1]. Which is
> >      basically about adding a stateless behavior to the Identity bean.
> >
> >      Today the Identity bean is session scoped, which implies that an
> >      authenticated user has a corresponding session on the server. That is
> >      fine when you're using JSF as view technology and the JESSIONID
> >      cookie is used to track user session. Or even using HTML5 and JS from
> >      a browser. The point here is that you don't need to send anything
> >      special in order to know that a specific request came from an
> >      previously authenticated user. The cookie is always sent to and from
> >      the server.
> >
> >      Recently, after some discussions about making PL even more suitable
> >      for mobile, we decided to add a stateless behavior to the Identity
> >      bean. Basically, instead of creating a session on the server for each
> >      authenticated user, we don't store anything. Every data consumed and
> >      produced during the authentication process is destroyed once the
> >      request is finished. This is a very important requirement when you
> >      don't want to consume server resources with users sessions, specially
> >      if you're writing a RESTful API. Another example is Anil's work to
> >      integrate Apache Camel with PL.
> >
> >      Usually, those use cases are based on a token which is issued after a
> >      successful authentication. Subsequent calls to protected services
> >      will then require the token to be validated in order to know if the
> >      request is from an authenticated user or not. Or even check if the
> >      token is still valid, etc.
> >
> >      We're pretty sure about adding this stateless nature to the Identity
> >      bean. But we would like to know from you if we should also support
> >      both "natures" from the same application. In other words, if we
> >      should allow the same application to use both stateless and stateful
> >      versions of the Identity bean. The use case that may justify that is
> >      when your services could support both JSF and HTML5 clients, where
> >      the latter do not use the JSESSIONID to track user session but a
> >      specific token.
> >
> >      Any thoughts ?
> >
> > [1] https://issues.jboss.org/browse/PLINK-400
> >
> > Regards.
> > Pedro Igor
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>