Reporte de los errores que voy encontrando y su solución en tecnología java jboss seam jsf rich faces jpa hibernate
20 de septiembre de 2011
19 de septiembre de 2011
Securing jboss aplications
Fuente
http://www.datadisk.co.uk/html_docs/java_app/jboss5/jboss5_securing_web_apps.htm
There are three security related subjects
Authorization is the process of verifying that a user has sufficient privileges to access an application resource, JBoss uses the common mechanism of roles to archive this, by assigning roles to a user then giving access to resources to the role, the user will be able to access the resource, this is commonly known as role-based authorization.
JBoss Security SX Framework
JBoss uses the JBoss security SX framework, which builds on top of the Java Authentication and Authorization Service (JAAS) which secures all the Java EE technologies running in the application.

A incoming component request is routed to a JBoss SX component called a security domain, an abstraction used to secure all requests made to a component, the security domain performs any necessary checks and notifies the component whether the user can proceed or not. The security domain knows how to use one or more login modules to load security data from a data source. Security domains are configured at the server level and can be used by any component within the server. Security domains are bound into JNDI (see Tomcat JNDI for information on JNDI) when the server starts, JNDI context maps a component to a security domain. This information in in the server/xxx/conf/login-config.xml file.
The above example is the jmx-console login authorization, it starts off defining the security domain name "jmx-console", this name is the one bound into JNDI which would be java:/jaas/jmx-console, all bound security domains start with java:/jaas namespace. One note is that JBoss only bounds the security domain into JNDI after you deploy an application that references the security domain. The login-module points to a login module (Java class), you can point it to more than one if you need to, the module will load security information from a file in this case but can use a database or LDAP. The module-options obviously is used by the login-module to obtain the file names, so check what options your particular module will use.
JBoss SX provides a feature called dynamic login configuration that allows you to define security in your application archive rather than in the server's login-config.xml file. To enable this feature, you have to create and deploy a MBean for the service to the server's server/xxx/deploydirectory. This file can be named anything you like as long as it has the suffix -service.xml, this enables the appropriate JBoss deployer to pick it up and deploy it as a MBean service.
Logging Additional Security
By default security logging is minimal, to increase this update the server/xxx/conf/jboss-log4j.xml
Secure Communications
When sending data over the wire (network), you should be aware of three aspects of secure communication
There are two types of encryption
To ensure that the encrypted message you receive from the sender is actually the sender you think you are communicating with, you use apublic key certificate which is a digital certificate that consists of some information about the certificate holders identity and a public key. To verify that the public key belongs to the user whose identity is on the certificate, a CA (Certificate Authority) signs the certificate. There are a number of public CA's that charge for public key certificates, VeriSign, Thawte and Entrust.
To get a signed certificate, you first generate a self-signed certificate and use it to create a Certificate Signing Request (CSR). The CSR and a few hundred bucks is then sent to the CA who validates your identity and then sends back a signed certificate. You can also create your own self-signed certificates which is a good idea when using them internally.
To create your own certificates the JVM comes with a tool called keytool, this tool can be used for the following

The JVM comes with a keystore that has many public key certificates, this type of keystore is a truststore, if you need to import any certificates in to the truststore use the below command
When using secure communications the server has to have a certificate, but the client does not. You can authenticate the client if required to do so although this is uncommon (normally use login/password authentication to identify the client) , this is called mutual authentication.
Configuring an SSL-aware security domain
It is very simple to setup SSL through the HTTP connector, you cannot setup an SSL-aware security domain in the login-config.xml file, you must define an MBean instance of Jaas SecurityDomain that points to a truststore.

Create a file (see below example) that ends with -service.xml and place it in the server/xxx/deploy directory
If you want your security domain to do authentication and authorization as well, you still need to define a security domain in your login-config.xml file
Configuring Login Modules
A JBoss SX login module knows how to access a security data source in order to load a users password and role information. Login modules are configured with security domains, each security domain can have one or more login modules, they are configured in the login-config.xmlfile.
I have supplied a couple of examples of the most commonly used ones, but you can use any of the login modules, don't forget to lookup the options that are available for each module.
http://www.datadisk.co.uk/html_docs/java_app/jboss5/jboss5_securing_web_apps.htm
Securing Applications
Security can be compromised in many ways, unauthorized users may access your applications data, someone may intercept a message being transmitted between two users, or crackers may expose vulnerabilities in your network or application server, giving them access to run commands on your O/S.There are three security related subjects
- Authentication
- Authorization
- Secure Communications
Authorization is the process of verifying that a user has sufficient privileges to access an application resource, JBoss uses the common mechanism of roles to archive this, by assigning roles to a user then giving access to resources to the role, the user will be able to access the resource, this is commonly known as role-based authorization.
JBoss Security SX Framework
JBoss uses the JBoss security SX framework, which builds on top of the Java Authentication and Authorization Service (JAAS) which secures all the Java EE technologies running in the application.
A incoming component request is routed to a JBoss SX component called a security domain, an abstraction used to secure all requests made to a component, the security domain performs any necessary checks and notifies the component whether the user can proceed or not. The security domain knows how to use one or more login modules to load security data from a data source. Security domains are configured at the server level and can be used by any component within the server. Security domains are bound into JNDI (see Tomcat JNDI for information on JNDI) when the server starts, JNDI context maps a component to a security domain. This information in in the server/xxx/conf/login-config.xml file.
| example of a security domain (login-conf.xml) | <application-policy name="jmx-console"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="usersProperties">props/jmx-console-users.properties</module-option> <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option> </login-module> </authentication> </application-policy> |
JBoss SX provides a feature called dynamic login configuration that allows you to define security in your application archive rather than in the server's login-config.xml file. To enable this feature, you have to create and deploy a MBean for the service to the server's server/xxx/deploydirectory. This file can be named anything you like as long as it has the suffix -service.xml, this enables the appropriate JBoss deployer to pick it up and deploy it as a MBean service.
| Example MBean dynamic login config | <server> <mbean code="org.jboss.security.auth.login.DynamicLoginConfig" name="jboss:service=DynamicLoginConfig"> <attribute name="AuthConfig">dynamic-login-config.xml</attribute> <depends option-attribute-name="LoginConfigService">jboss.security:service=XMLLoginConfig</depends> <depends option-attribute-name="SecurityManagerService">jboss.security:service=JaasSecurityManager</depends> </mbean> </server> |
By default security logging is minimal, to increase this update the server/xxx/conf/jboss-log4j.xml
| increase security logging | <category name="org.jboss.security"> <priority value="TRACE" class="org.jboss.logging.XLevel"/> </category> <category name="org.jboss.web.tomcat.security"> <priority value="TRACE" class="org.jboss.logging.XLevel"/> </category> <category name="org.apache.catalina"> <priority value="DEBUG"/> </category> Note: don't forget to comment out the threshold parameter in the appender that you want the logging messages to appear in. |
When sending data over the wire (network), you should be aware of three aspects of secure communication
- Confidentiality - protect a message from being read by others
- Data Integrity - make sure the message has not been tampered with
- Source Integrity - give assurance to the recipient that the message has been sent by the sender he/she thinks he/she is communicating with
There are two types of encryption
| symmetric | This is like a user having a secret message that he/she puts into a box and secures it with a padlock, if your friend has the same key to the padlock you can both open and close it knowing no else can. Symmetric works in the same manor by using a secret key, a message is encrypted with a secret key and decrypted with the same key, as long as the key is not comprised the two parties can communicate securely. |
| asymmetric | Public key encryption (asymmetric encryption) uses a pair of mathematically associated keys, after a message is encrypted with one, it can only be decrypted with the other. The keys are called public and private, the public you can give to anyone and the private you keep yourself, only the private key can decrypt messages encrypted by the public key. What this means is that you can freely distribute the public to anyone, the only drawback is that this mechanism is slower. |
To get a signed certificate, you first generate a self-signed certificate and use it to create a Certificate Signing Request (CSR). The CSR and a few hundred bucks is then sent to the CA who validates your identity and then sends back a signed certificate. You can also create your own self-signed certificates which is a good idea when using them internally.
To create your own certificates the JVM comes with a tool called keytool, this tool can be used for the following
- Generating and storing self-signed public/private key pairs
- Generating CSRs
- Importing public certificates that you have had signed by a CA
- Importing public certificates for some other party that you trust
| Generate a keystore and self-signed certificate | keytool -genkey -alias "selfsigned" -keyalg RSA -keystore keystore.pfv -storepass "password123" -validity 360 |
| Generate a keystore and Export the CSR file to get signed then Import the signed-cert from the CA | keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.pfv keytool -certreq -alias mydomain -keystore keystore.pfv -file getMeSigned.csr keytool -import -trustcacerts -alias mydomain -keystore keystore.pfv -file signedCertificate.crt |
| Export the certficate from the keystore to distribute it | keytool -export -alias mydomain -keystore keystore.pfv -file mydomain.crt |
| Print keystore information | keytool -list -v -keystore keystore.pfv keytool -list -v -keystore keystore.pfv -alias mydomain |
| importing into the trust store | keytool -import -alias myserver -file server.csr -keystore C:\jdk1.6.0_12\jre\lib\secruity\cacerts |
| specify on the commandline | java -Djavax.net.ssl.trustStore=<file> -Djavax.net.ssl.trustStorePassword=<pass> |
| Authentication Strategy | Who wants to verify the other party's identity | Who needs public key? |
| Server Authentication | Client | Server |
| Mutual Authentication | Client and Server | Client and Server |
It is very simple to setup SSL through the HTTP connector, you cannot setup an SSL-aware security domain in the login-config.xml file, you must define an MBean instance of Jaas SecurityDomain that points to a truststore.
Create a file (see below example) that ends with -service.xml and place it in the server/xxx/deploy directory
| Example SSL-aware security domain defined MBean | <server> <mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.security:service=MySecurityDomain"> <constructor> <arg type="java.lang.String" value="my-security-domain"/> </constructor> <attribute name="KeyStoreURL">${jboss.server.home.dir}/conf/server.truststore</attribute> <attribute name="KeyStorePass">servercert</attribute> <depends>jboss.security:service=JassSecurityManager</depends> </mbean> </server> Note: this will now bind to JNDI as java:/jaas/my-security-domain |
| login-config.xml | <application-policy name="my-security-domain"> ... </application-policy> |
A JBoss SX login module knows how to access a security data source in order to load a users password and role information. Login modules are configured with security domains, each security domain can have one or more login modules, they are configured in the login-config.xmlfile.
| Login Module | Description |
| BaseCertLoginModule | Authenticates client certificates, must be stacked with another login module that does authorization |
| CertRolesLoginModule | An extension of BaseCertLoginModule that authenticates against client certificates and authorizes against properties files |
| ClientLoginModules | Used by standalone clients that want to log into a secure server |
| DatabaseCertLoginModule | An extension of BaseCertLoginModule that authenticates against client certificates and authorizes against a database |
| DatabaseServerLoginModule | Loads user/role information from a database |
| IndentityLoginModule | a testing login module that causes all users to authenticate with the same credentials |
| LdapExtLoginModule | Loads user/roles information from a LDAP server (supports hierarchical role structure) |
| ldapLoginModule | Loads user/roles information from a LDAP server (only works with flat role structures) |
| RunASLoginModule | Can be stacked with another login module to define the run-as status that they use while they're authenticating, useful if you need to call a secured EJB that's responsible for authenticating users. |
| SimpleServerLoginModule | A testing login module that allows any role with a null password to authenticate |
| SRPCacheLoginModule | Used to authenticate users using the Secure Remote Password (SRP) protocol |
| SRPLoginModule | Used by standalone clients that want to authenticate using the SRP protocol |
| UsersRolesLoginModule | Loads user/roles information from property files |
| UserRolesLoginModule | <application-policy name="my-security-domain"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="usersProperties">my-users.properties</module-option> <module-option name="rolesProperties">my-roles.properties</module-option> </login-module> </authentication> </application-policy> # my-user.properies file pvalle=password willhay=password1 normanwisdom=password2 # my-role.properies file pvalle=admin,movies willhay=movies normanwisdom=movies |
| DatabaseServerLoginModule | <application-policy name="database-domain"> <authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> <module-option name="dsJndiName">java:/OracleDS</module-option> <module-option name="principalsQuery">select passwd from users where userid=?</module-option> <module-option name="rolesQuery">select roleid, 'Roles' from roles where userid=?</module-option> </login-module> </authentication> </application-policy> |
17 de agosto de 2011
Eclipse Cambiar tipo de letra
WINDOW->PREFERENCES
Y en el arbol:
GENERAL->APPEARANCE->COLORS AND FONTS
dentro de la rama BASIC, la última opcion es Text Font, que es la fuente del editor de texto normal. Pulsas el botón Change y pones la fuente que quieras.
Y en el arbol:
GENERAL->APPEARANCE->COLORS AND FONTS
dentro de la rama BASIC, la última opcion es Text Font, que es la fuente del editor de texto normal. Pulsas el botón Change y pones la fuente que quieras.
13 de junio de 2011
Dividir Faces Config
Para añadir un segundo fichero config deberemos añadir las siguientes líneas al fichero web.xml.
<context-param>
<param-name>javax.faces.CONFIG_FILES </param-name>
<param-value>/WEB-INF/faces-config.xml, /WEB-INF/tiles-defs.xml</param-value>
</context-param>
26 de abril de 2011
Diseño Modelado con Seam
Cuando se arma el modelo de las entities en seam, la visibilidad elegida define la navegación generada por el seam-gen.
Tanto para la visibilidad ManyToOne o ManyToMany en las pantallas crea tabs para contemplar esta visibilidad.
Por lo tanto una regla a la hora de elegir la visibilidad del modelo, sería identificar las entities que son más relevantes ( aquellas que llevan ABM ) y que sean ellas quienes tengan visibilidad sobre el resto.
Tanto para la visibilidad ManyToOne o ManyToMany en las pantallas crea tabs para contemplar esta visibilidad.
Por lo tanto una regla a la hora de elegir la visibilidad del modelo, sería identificar las entities que son más relevantes ( aquellas que llevan ABM ) y que sean ellas quienes tengan visibilidad sobre el resto.
25 de abril de 2011
SEAM page error "duplicate Id for a component selectParent"
Yes, it is a bug. Quick solution:look at seam-home/seam-gen/view/edit.page.xml.ftl
and change the following line:
<s:button id="${'#'}{${homeName}.instance.${property.name} != null ? 'changeParent' : 'selectParent'}" value="${'#'}{${homeName}.instance.${property.name} != null ? 'Change' : 'Select'} ${property.name}"
for:
<s:button id="${'#'}{${homeName}.instance.${property.name} != null ? 'changeParent${property.name}' : 'selectParent${property.name}'}" value="${'#'}{${homeName}.instance.${property.name} != null ? 'Change' : 'Select'} ${property.name}"Enjoy!!!
extraido de http://seamframework.org/Community/PageErrorDuplicateIdForAComponentSelectParent#comment84431
Esto soluciona el bug del generador de seam
en mi caso debí cambiar la página
Esto
<div class="actionButtons">
<s:button id="#{beneficiarioHome.instance.direccionContacto != null ? 'changeParent ' : 'selectParent '}"
value="#{beneficiarioHome.instance.direccionContacto != null ? 'Change' : 'Select'} direccionContacto"
view="/DireccionContactoList.xhtml">
<f:param name="from" value="BeneficiarioEdit"/>
</s:button>
por esto:
<div class="actionButtons">
<s:button id="#{beneficiarioHome.instance.direccionContacto != null ? 'changeParentdireccionContacto ' : 'selectParentdireccionContacto '}"
value="#{beneficiarioHome.instance.direccionContacto != null ? 'Change' : 'Select'} direccionContacto"
view="/DireccionContactoList.xhtml">
<f:param name="from" value="BeneficiarioEdit"/>
</s:button>
Y ESO TAMPOCO ANDUVO ASÍ QUE LE SAQUE EL id="#{bla bla}"
Suscribirse a:
Entradas (Atom)