[jira] [Closed] (WSS-299) UsernameToken Salt Mac/Encryption Flag on Wrong End of Array
[ https://issues.apache.org/jira/browse/WSS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-299. --- UsernameToken Salt Mac/Encryption Flag on Wrong End of Array Key: WSS-299 URL: https://issues.apache.org/jira/browse/WSS-299 Project: WSS4J Issue Type: Bug Affects Versions: 1.5.11, 1.6.1 Reporter: Patrick Ryan Assignee: Colm O hEigeartaigh Fix For: 1.5.12, 1.6.2 In UsernameToken Profile key derivation, the flag that indicates the use for the salt is being placed on the wrong end. It should be at index 0 but is being placed at index 15. See org.apache.ws.security.message.token.UsernameToken.generateSalt(boolean). The UsernameToken Profile 1.1 spec says The high order 8 bits of the Salt will have the value of 01 if the key is to be used in a MAC and 02 if the key is to be used for encryption. The remaining 120 low order bits of the Salt should be a random value. Java is big endian, which means the high order values come first (i.e. high byte is at index 0 of a byte array). From http://en.wikipedia.org/wiki/Endianness The usual contrast is whether the most-significant or least-significant byte is ordered first - i.e. at the lowest byte address - within the larger data item. A big-endian machine stores the most-significant byte first (at the lowest address), and a little-endian machine stores the least-significant byte first. In these standard forms, the bytes remain ordered by significance. Looking at other UsernameToken Profile implementations turned up this example: http://blogs.oracle.com/SureshMandalapu/entry/passwordderivedkeys_support_in_metro which clearly shows the salt flag is at index 0 of the byte array: Absds/FHfgh/swderfa== decodes to 01bb1db3f1477e087fb3075eadf6 (when printing the byte array in hex starting at index 0). And, in my discussion with Colm to confirm this issue, I asked what should be done about salt validation. Here is what he said: Hi Patrick, Doesn't that mean index 0 of an array should hold the most significant value? Yes, I think you're right. Could you submit a JIRA and patch? * check both ends and if only one end is either 1 or 2, then use that to validate the usage of the derived key * if both ends contain either a 1 or 2 then skip validation on the usage of the derived key * if neither end has a 1 or a 2, then fail validation That sounds reasonable to me. I think it could be extended so that we validate that the correct flag has been set for signature verification, or for decryption, when using a derived key - I don't think the current code does this. Thanks, Colm. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-296) SubjectLocality is missing from AuthenticationStatementBean
[ https://issues.apache.org/jira/browse/WSS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-296. --- SubjectLocality is missing from AuthenticationStatementBean --- Key: WSS-296 URL: https://issues.apache.org/jira/browse/WSS-296 Project: WSS4J Issue Type: Bug Components: WSS4J Core, WSS4J Handlers Affects Versions: 1.6 Environment: Eclipse, Maven, Tomcat Reporter: Srinivasa Kukatla Assignee: Colm O hEigeartaigh Labels: api-change Fix For: 1.6.2 Attachments: AuthenticationStatementBean.java, Saml2ComponentBuilder.java, SubjectLocalityBean.java As per the saml2 core specification, Authentication Statement can have an optional SubjectLocality as defined in the saml xsd below: complexType name=AuthnStatementType complexContent extension base=saml:StatementAbstractType sequence element ref=saml:SubjectLocality minOccurs=0 / element ref=saml:AuthnContext / /sequence attribute name=AuthnInstant type=dateTime use=required / attribute name=SessionIndex type=string use=optional / attribute name=SessionNotOnOrAfter type=dateTime use=optional / /extension /complexContent /complexType But, AuthenticationStatementBean does not have the SubjectLocalityBean. Please find the attached SubjectLocalityBean, as well as the AuthenticationStatementBean updated with the SubjectLocalityBean. Example: saml2:AuthnStatement AuthnInstant=2009-04-16T13:10:39.093Z saml2:SubjectLocality Address=11.01.124.22 DNSName=test/saml2:SubjectLocality saml2:AuthnContext saml2:AuthnContextClassRefurn:oasis:names:tc:SAML:2.0:ac:classes:X509 /saml2:AuthnContextClassRef /saml2:AuthnContext /saml2:AuthnStatement -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-301) WSS4J 1.6 incorrectly using XML-Security ResourceResolvers
[ https://issues.apache.org/jira/browse/WSS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-301. --- WSS4J 1.6 incorrectly using XML-Security ResourceResolvers -- Key: WSS-301 URL: https://issues.apache.org/jira/browse/WSS-301 Project: WSS4J Issue Type: Bug Affects Versions: 1.6.1 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.6.2 Attachments: wss4j-1.6.2-SNAPSHOT.jar WSS4J 1.6.x is incorrectly using XML-Security ResourceResolvers to resolve DOM Elements for use in signature creation and verification. WSS4J uses a custom IdResolver implementation to call a custom ResourceResolverSpi instance. This IdResolver implementation uses internal org.jcp.* classes, and this is causing problems when using JDK 1.6 for signature creation and validation in some containers (Jetty). WSS4J should be using the JSR-105 API instead to find and supply elements for signature/creation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-251) Support WSS Kerberos Token Profile
[ https://issues.apache.org/jira/browse/WSS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-251. --- Support WSS Kerberos Token Profile -- Key: WSS-251 URL: https://issues.apache.org/jira/browse/WSS-251 Project: WSS4J Issue Type: New Feature Reporter: Christian Schneider Assignee: Colm O hEigeartaigh Fix For: 1.6.2 Currently wss4j does not support the kerberos token profile. In most windows enterprise environments and in some unix environments kerberos is available by default. So it would be nice to have this feature to allow single sign on for clients to e.g. webservices. I can post sample code that shows how to create a service ticket on the client and how to validate it on the server. Would this help? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-302) Unable to load keystore/truststore when it cannot be loaded from an InputStream
[ https://issues.apache.org/jira/browse/WSS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-302. --- Unable to load keystore/truststore when it cannot be loaded from an InputStream --- Key: WSS-302 URL: https://issues.apache.org/jira/browse/WSS-302 Project: WSS4J Issue Type: Bug Components: WSS4J Core Affects Versions: 1.6.1 Reporter: Sergey Zhemzhitsky Assignee: Colm O hEigeartaigh Fix For: 1.6.2 Attachments: no_inpustream.patch Unable to load keystore/truststore when it cannot be loaded from an InputStream. According to the javadocs http://download.oracle.com/javase/6/docs/api/java/security/KeyStore.html#load%28java.io.InputStream,%20char[]%29 it should be possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-300) SubjectKeyIidentifier (SKI) incorrectly calculated for 2048-bit RSA key
[ https://issues.apache.org/jira/browse/WSS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-300. --- SubjectKeyIidentifier (SKI) incorrectly calculated for 2048-bit RSA key --- Key: WSS-300 URL: https://issues.apache.org/jira/browse/WSS-300 Project: WSS4J Issue Type: Bug Components: WSS4J Core Affects Versions: 1.5.11, 1.6.1 Environment: Tomcat 5, Solaris 10, Java 1.4 and Tomcat 6, Win XP, Java 6 Reporter: Linton Miller Assignee: Colm O hEigeartaigh Fix For: 1.5.12, 1.6.2 Attachments: CryptoBase.java.patch, DERDecoder.java, X509SubjectPublicKeyInfo.java, X509SubjectPublicKeyInfo.java, broken.xml, client.wsdd, correct.xml, rsa2048.jks, rsa2048.jks, test.cypto.properties The crypto function to get the SubjectKeyIdentifier from an X509Certificate has incorrect hard-coded assumptions about the size of the encoded information, meaning the calculation of the SKI from a 2048-bit RSA key is incorrect. The method org.apache.ws.security.components.crypto.CryptoBase.getSKIBytesFromCert does not parse the DER encoding of information, but just tries to pick out the piece of the byte array that corresponds to the content of interest. However, that approach fails because the DER encoding is variable length, depending on the size of the data being encoded. e.g. a 1024-bit key in a DER BIT STRING takes 4 bytes header + 140 bytes data to encode, whereas a 2048-bit key takes 5 bytes header + 270 bytes data; the header is one byte longer for the larger key, so the data starts at a different point in the array. To fix this, the DER data structures should be properly processed, reading the DER header bytes to determine the length of each data element (that also allows the generalization of handling any X.509 encoded public key, rather than just RSA keys as currently coded). Attached is a suggested patch (against WSS4J 1.6.1) that implements this idea: it processes the SubjectPublicKeyInfo and SubjectKeyIdentifier DER-encoded byte arrays according to their ASN.1 definitions from RFC 3280/5280 to pick out the desired data bytes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-294) Merlin doesn't support physical providers with no keystore file
[ https://issues.apache.org/jira/browse/WSS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-294. --- Merlin doesn't support physical providers with no keystore file --- Key: WSS-294 URL: https://issues.apache.org/jira/browse/WSS-294 Project: WSS4J Issue Type: Bug Components: WSS4J Handlers Affects Versions: 1.6.1 Environment: using PKCS11 provider Reporter: rotem a Assignee: Colm O hEigeartaigh Fix For: 1.6.2 Original Estimate: 1h Remaining Estimate: 1h At Merlin.loadProperties, in order for the load method to be called, there must be a non null inputStream. In case of physical keystore (like smart card), there is no keystore inputStream, the keystore is not loaded and later on we'll get an error when we try to retrive a certificate from the keystore. The solution is to allow not getting a keystore file and in this case just send a null inputStream to the load method (it works). There is a workaround: creating a new class which extends Merlin and just override the loadProperties method (though it's not perfect cause we can't set the loadCACerts property (it's private). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (WSS-297) Subject Bean is missing NameID Format variable
[ https://issues.apache.org/jira/browse/WSS-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed WSS-297. --- Subject Bean is missing NameID Format variable -- Key: WSS-297 URL: https://issues.apache.org/jira/browse/WSS-297 Project: WSS4J Issue Type: Bug Components: WSS4J Core, WSS4J Handlers Affects Versions: 1.6 Reporter: Srinivasa Kukatla Assignee: Colm O hEigeartaigh Labels: api-change Fix For: 1.6.2 Attachments: Saml2ComponentBuilder.java, SubjectBean.java As per the saml2core specification, we have the following for the Subject NameID: element name=NameID type=saml:NameIDType / complexType name=NameIDType simpleContent extension base=string attributeGroup ref=saml:IDNameQualifiers / attribute name=Format type=anyURI use=optional / attribute name=SPProvidedID type=string use=optional / /extension /simpleContent /complexType NameID has the optional Format Attribute, we can specify different NameID Formats such as email, X509 etc. That is missing in the subject Bean. Please find the updated Subject Bean, added a field for the NameIDFormat. Example : saml2:Subject saml2:NameID Format=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddresss...@abc.com/saml2:NameID saml2:SubjectConfirmation /saml2:SubjectConfirmation /saml2:Subject -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
Jenkins build is back to normal : wss4j-trunk #195
See https://builds.apache.org/job/wss4j-trunk/195/ - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[VOTE] - Release Apache WSS4J 1.5.12
All, This is a vote to release Apache WSS4J 1.5.12. 1.5.11 was released last January so it's high time this was released. Issues Fixed: https://issues.apache.org/jira/browse/WSS/fixforversion/12316045 Svn tag: https://svn.apache.org/repos/asf/webservices/wss4j/tags/1_5_12/ Distribution: http://people.apache.org/~coheigea/stage/wss4j/1.5.12/dist/ Maven artifacts: http://people.apache.org/~coheigea/stage/wss4j/1.5.12/maven/ Here is my +1 (binding). -- Colm O hEigeartaigh http://coheigea.blogspot.com/ Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
