Moving picketbox to Github
by Stuart Douglas
Hi,
Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc.
Stuart
10 years, 7 months
Vault to store sensitive data
by Bruno Oliveira
Good morning, I would like to know if Vaults from PicketBox are specific
for datasources or any kind of sensitive data. I would like to store a
key material, used for encryption and not sure if this is the correct
configuration for it:
- standalone.xml
<system-properties>
<property name="key-material"
value="${VAULT::ds_SecurityVaultDS::password::2DyuLAae8wP.pSsrT/gGhn}"/>
</system-properties>
<vault>
<vault-option name="KEYSTORE_URL"
value="/servers/wildfly-current/vault/vault.keystore"/>
<vault-option name="KEYSTORE_PASSWORD"
value="MASK-2DyuLAae8wP.pSsrT/gGhn"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="2bzeScxo"/>
<vault-option name="ITERATION_COUNT" value="16"/>
<vault-option name="ENC_FILE_DIR"
value="/servers/wildfly-current/vault/"/>
</vault>
This is the stack trace when Wildfly is initialized:
https://gist.github.com/abstractj/4542c7cf1aa8a36ebad9. I would
appreciate any pointers to the documentation.
--
abstractj
10 years, 7 months
[PLINK-400] - Stateless Nature of the Identity Bean
by Pedro Igor Silva
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
10 years, 8 months
