-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate password for jsf client state encryption per VM #102
Comments
All our oxAuth pages contains one hidden property. Example: I think I find good answer: http://stackoverflow.com/questions/28231372/com-sun-faces-clientstatesavingpassword-recommendations-for-actual-password In our case we uses: jsf-impl 1.2.12. I decompiled it and find inside: com.sun.faces.renderkit.ResponseStateManagerImpl Hence it really uses encryption for javax.faces.ViewState if there next section in web.xml: 7641eb8 |
But according to commons-collections 3.2.2 release notes it do secure serialization now. Hence web.xml env property "ClientStateSavingPassword" probably not needed. We need to make sure that jsf 1.2.12 do secure serialization with commons-collections 3.2.2. if yes we can remove env section from web.xml |
See line 169 of ResponseStateManagerImpl. I assume we always need the password otherwise we will get simple input stream instead of encrypted one. (guard will be null if password is not specified in web.xml)
|
yes, according to this example we have to set password
|
It's not convinient to update web.xml in every VM to secure it... |
Isn't it easier to upgrade jsf, which already generates passwords on the fly.? Then we will also benefits from all other new stuff there. |
Actually, we can generate web.xml during installation. So it doesn't seem like such a big deal to render a random password. |
In setup.py we have method which update oxCas.war during install. We can use this method as reference for oxath.war update: https://github.com/GluuFederation/community-edition-setup/blob/master/setup.py#L999 |
ok, I changed my mind. Having to recreate the war is messy and would make upgrades harder. |
I have tried to find solution for this today. 100% pure programmatic way is not possible because JNDI was developed for services integration. Also when I try to change JNDI context properties it throw exception that Context is read only. I find another solution. It's not bed too: GluuFederation/community-edition-setup@9d2f97d Setup put file $TOMCAT_HOME/conf/Catalina/localhost/oxauth.xml during install. This value override default value in oxauth.war/WEB-INF/web.xml: |
We need to generate password in next section per VM:
7641eb8
The text was updated successfully, but these errors were encountered: