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

From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; To: security-dev(a)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?

- 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 _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev