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

[Anil Saldhana]

On 04/01/2014 09:24 AM, Pedro Igor Silva wrote:
> ----- 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.
Then it should be fine as long as we have proper documentation on usage 
patterns. :)

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