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

[Anil Saldhana]

Pedro,

- how does the programmer figure out he is using the Identity bean in a 
stateless scope and other usage: session scope?
- will it add complexity to the internal implementation?

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