[jira] [Commented] (SYNCOPE-199) Refocus on user deletion page
[ https://issues.apache.org/jira/browse/SYNCOPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556237#comment-13556237 ] Colm O hEigeartaigh commented on SYNCOPE-199: - Thanks for the fix! Colm. Refocus on user deletion page - Key: SYNCOPE-199 URL: https://issues.apache.org/jira/browse/SYNCOPE-199 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Marco Di Sabatino Di Diodoro Priority: Trivial Fix For: 1.1.0 SYNCOPE-189 added the ability to close a window on pressing ESC. It would be nice when deleting a user to automatically reselect the deletion page, so that the user can just press ESC to close the window. Currently you need to click on the deletion page before pressing ESC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-295) If AccountId is selected when creating a Resource Mapping, then make it mandatory
Colm O hEigeartaigh created SYNCOPE-295: --- Summary: If AccountId is selected when creating a Resource Mapping, then make it mandatory Key: SYNCOPE-295 URL: https://issues.apache.org/jira/browse/SYNCOPE-295 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Trivial Fix For: 1.1.0 If AccountId is selected when creating a Resource Mapping, then make it mandatory + remove the ability to edit the Mandatory field. As an Account Id mapping is always mandatory, then this makes creating new resource mappings slightly quicker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
Colm O hEigeartaigh created SYNCOPE-297: --- Summary: External Attributes are showing up for AccoundId/Password in Resource User Mappings Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-299) Add row to display selector in resources
[ https://issues.apache.org/jira/browse/SYNCOPE-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566381#comment-13566381 ] Colm O hEigeartaigh commented on SYNCOPE-299: - The functionality to display the row count is already there - but it relies on an authorization check for a RESOURCE_LIST entitlement which is not present. Colm. Add row to display selector in resources -- Key: SYNCOPE-299 URL: https://issues.apache.org/jira/browse/SYNCOPE-299 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.0.5 Reporter: Denis Signoretto Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 1.0.6, 1.1.0 Allow resources list to display more than 10 resources per page (add the Rows to display pager) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
[ https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-297: --- Assignee: Colm O hEigeartaigh External Attributes are showing up for AccoundId/Password in Resource User Mappings --- Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: Screenshot.png I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
[ https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566459#comment-13566459 ] Colm O hEigeartaigh commented on SYNCOPE-297: - Hi Jan, Could you elaborate on what exception you are getting? I am not seeing an exception there. I believe the problem is due to the functionality added in MappingTO on trunk. A AccountId MappingItemTO object has an external attribute name of __NAME__ and __PASSWORD__ for a Password object. On 1.0.x they just have null. This appears to be confusing the Wicket DropdownChoice, as it is getting initialized with a value that does not correspond to the choices (GIVENNAME + SURNAME) in this case. Questions: A) Should MappingItemTO have defined external attribute names added for AccountID/Passwords? B) If the answer to (A) is yes, then I can just remove the external attribute choices for AccountID/Password mappings. Colm. External Attributes are showing up for AccoundId/Password in Resource User Mappings --- Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: Screenshot.png I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
[ https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-297: Attachment: syncope-297.patch Hi guys, I'd like some feedback on the attached patch. It does two things: a) Removes the external attribute values for AccountId/Passwords in the MappingTO class (ignored by core anyway) b) Disables the ext attr dropdown list when it's an account id or password This fixes the problem reported in the JIRA. I've run into a similar problem though. If you edit the user mappings, and de-select the AccountId checkbox and click on the extr attribute dropdown list (but don't select a value, just click on it), and then re-click on AccountId, you get a extAttrName is required error message. Any ideas? Colm. External Attributes are showing up for AccoundId/Password in Resource User Mappings --- Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: Screenshot.png, syncope-297.patch I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
[ https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567678#comment-13567678 ] Colm O hEigeartaigh commented on SYNCOPE-297: - Hi Francesco, Great thanks - I'll review + apply it. I'll merge the mandatory condition thing separately. Colm. External Attributes are showing up for AccoundId/Password in Resource User Mappings --- Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: Screenshot.png, syncope-297-ilgrosso.patch, syncope-297.patch I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings
[ https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-297. - Resolution: Fixed External Attributes are showing up for AccoundId/Password in Resource User Mappings --- Key: SYNCOPE-297 URL: https://issues.apache.org/jira/browse/SYNCOPE-297 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: Screenshot.png, syncope-297-ilgrosso.patch, syncope-297.patch I have a Database Connector for a H2 backend with a simple table. I am creating a Resource User Mapping of Username - Account Id, Password - Password, and a User schema 'surname' attribute - SURNAME column in the table. The Resource now creates ok, however when I edit it and look at the User mappings, I see that another column name 'GIVENNAME' is appearing as the external attribute for the User Account Id and Password mappings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-295) If AccountId is selected when creating a Resource Mapping, then make it mandatory
[ https://issues.apache.org/jira/browse/SYNCOPE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-295. - Resolution: Fixed If AccountId is selected when creating a Resource Mapping, then make it mandatory - Key: SYNCOPE-295 URL: https://issues.apache.org/jira/browse/SYNCOPE-295 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Trivial Fix For: 1.1.0 If AccountId is selected when creating a Resource Mapping, then make it mandatory + remove the ability to edit the Mandatory field. As an Account Id mapping is always mandatory, then this makes creating new resource mappings slightly quicker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-306) 'Mandatory' error in Console when propagating Virtual Attributes
Colm O hEigeartaigh created SYNCOPE-306: --- Summary: 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-306) 'Mandatory' error in Console when propagating Virtual Attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570131#comment-13570131 ] Colm O hEigeartaigh commented on SYNCOPE-306: - Fix confirmed, thanks! Colm. 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-215) ReadOnly option for virtual attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-215. - Resolution: Fixed ReadOnly option for virtual attributes -- Key: SYNCOPE-215 URL: https://issues.apache.org/jira/browse/SYNCOPE-215 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.1-incubating Environment: Tomcat 7, Microsoft 2008 Server with ActiveDirectory, PostgreSQL 9.2.1 Reporter: Jan Bernhardt Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: syncope-215-console.patch, syncope-215-console.patch There are situations when you can not change an attribute value of a remote resource, since it is read only at the remote resource. To avoid exceptions within syncope it would be important to set virtual attributes to read only also. This would prevent administrators of changing an attribute that can not be changed within the backend systems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated SYNCOPE-313:
Fix Version/s: 1.2.0
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (SYNCOPE-315) Persistent feedback messages
[ https://issues.apache.org/jira/browse/SYNCOPE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reopened SYNCOPE-315: - I'm seeing the following error: ERROR: Wicket.Ajax.Call.processComponent: Component with id [[feedback4a]] was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. The scenario is when you add a new User Mapping in a Resource. Persistent feedback messages -- Key: SYNCOPE-315 URL: https://issues.apache.org/jira/browse/SYNCOPE-315 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5, 1.1.0 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 Once feedback messages have been reported, they stay on the page until navigating away of that page: note that this does not apply to AJAX navigation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-318) No way to see Connector help message for multi-valued property
Colm O hEigeartaigh created SYNCOPE-318: --- Summary: No way to see Connector help message for multi-valued property Key: SYNCOPE-318 URL: https://issues.apache.org/jira/browse/SYNCOPE-318 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh When configuring a Connector in Syncope, it is possible to hover the mouse pointer over the textfield to see the corresponding help message associated with the property. However, when the property is a multi-valued field, no help message appears. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-293) Show information (version, license, ...)
[ https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-293: Attachment: Screenshot from 2013-02-19 15.png Here is a SNAPSHOT of the information panel in Firefox. My scenario is a new archetype project with version 5.3. Not sure if I am missing something here, or if this is a bug that's crept in since this issue was fixed. Colm. Show information (version, license, ...) Key: SYNCOPE-293 URL: https://issues.apache.org/jira/browse/SYNCOPE-293 Project: Syncope Issue Type: Improvement Components: console Reporter: Massimiliano Perrone Assignee: Massimiliano Perrone Fix For: 1.1.0 Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, Screenshot from 2013-02-19 15.png, welcomeOnChrome.png, wp.png Currently there is only a static label with core and console versions. Add a new Link to open a ModalPage with version and other project information (eg. link to license) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (SYNCOPE-293) Show information (version, license, ...)
[ https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reopened SYNCOPE-293: - Show information (version, license, ...) Key: SYNCOPE-293 URL: https://issues.apache.org/jira/browse/SYNCOPE-293 Project: Syncope Issue Type: Improvement Components: console Reporter: Massimiliano Perrone Assignee: Massimiliano Perrone Fix For: 1.1.0 Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, welcomeOnChrome.png, wp.png Currently there is only a static label with core and console versions. Add a new Link to open a ModalPage with version and other project information (eg. link to license) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames
Colm O hEigeartaigh created SYNCOPE-320: --- Summary: Support synchronizing role memberships from LDAP groupOfNames Key: SYNCOPE-320 URL: https://issues.apache.org/jira/browse/SYNCOPE-320 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 This task is to support synchronizing role memberships from LDAP groupOfNames. As reported in the following mailing list thread, it is not possible to synchronize role memberships from groupOfNames currently (only groupOfUniqueNames): http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html The solution is to update the LDAPMembershipSyncActions to query the Connector for the configured group member attribute. If none is defined, then just fall back to uniqueMember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames
[ https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-320: Attachment: syncope-320.patch A patch for this issue. Colm. Support synchronizing role memberships from LDAP groupOfNames - Key: SYNCOPE-320 URL: https://issues.apache.org/jira/browse/SYNCOPE-320 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: syncope-320.patch This task is to support synchronizing role memberships from LDAP groupOfNames. As reported in the following mailing list thread, it is not possible to synchronize role memberships from groupOfNames currently (only groupOfUniqueNames): http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html The solution is to update the LDAPMembershipSyncActions to query the Connector for the configured group member attribute. If none is defined, then just fall back to uniqueMember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames
[ https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-320. - Resolution: Fixed Support synchronizing role memberships from LDAP groupOfNames - Key: SYNCOPE-320 URL: https://issues.apache.org/jira/browse/SYNCOPE-320 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.0 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: syncope-320.patch This task is to support synchronizing role memberships from LDAP groupOfNames. As reported in the following mailing list thread, it is not possible to synchronize role memberships from groupOfNames currently (only groupOfUniqueNames): http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html The solution is to update the LDAPMembershipSyncActions to query the Connector for the configured group member attribute. If none is defined, then just fall back to uniqueMember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-293) Show information (version, license, ...)
[ https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-293: Attachment: Screenshot from 2013-02-20.png Sorry to be a PITA, but I'm seeing the above when launching Syncope in embedded mode! Colm. Show information (version, license, ...) Key: SYNCOPE-293 URL: https://issues.apache.org/jira/browse/SYNCOPE-293 Project: Syncope Issue Type: Improvement Components: console Reporter: Massimiliano Perrone Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, welcomeOnChrome.png, wp.png Currently there is only a static label with core and console versions. Add a new Link to open a ModalPage with version and other project information (eg. link to license) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-293) Show information (version, license, ...)
[ https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582261#comment-13582261 ] Colm O hEigeartaigh commented on SYNCOPE-293: - Yup that works, sorry for the noise. Colm. Show information (version, license, ...) Key: SYNCOPE-293 URL: https://issues.apache.org/jira/browse/SYNCOPE-293 Project: Syncope Issue Type: Improvement Components: console Reporter: Massimiliano Perrone Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, welcomeOnChrome.png, wp.png Currently there is only a static label with core and console versions. Add a new Link to open a ModalPage with version and other project information (eg. link to license) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-322) Can't create a new Role in Chromium
Colm O hEigeartaigh created SYNCOPE-322: --- Summary: Can't create a new Role in Chromium Key: SYNCOPE-322 URL: https://issues.apache.org/jira/browse/SYNCOPE-322 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Fix For: 1.1.0 Attachments: chromium.png, firefox.png If I start Syncope up with no existing roles, and navigate to the Roles tab, I can't find a way to create a new Role on Chromium. I'm attaching screenshots of the difference between Firefox and Chromium (on Ubuntu) - the latter is missing a icon to create the Role. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-324) Return User instead of Boolean from REST username + password query
Colm O hEigeartaigh created SYNCOPE-324:
---
Summary: Return User instead of Boolean from REST username +
password query
Key: SYNCOPE-324
URL: https://issues.apache.org/jira/browse/SYNCOPE-324
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Fix For: 1.1.0
The REST API GET /users?username={username}pwd={password} currently returns a
boolean. This task is to return the User instead, as per the mailing list
discussion here:
http://syncope-dev.1063484.n5.nabble.com/API-query-td5712965.html
If authentication is successful we should return 200 OK, if authentication
fails we should return 404 NOT FOUND.
Caching should be disabled for this URL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-332) User List sorting via Derived attributes column doesn't work
[ https://issues.apache.org/jira/browse/SYNCOPE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592131#comment-13592131 ] Colm O hEigeartaigh commented on SYNCOPE-332: - I don't think User list sorting will work for Virtual attributes either looking at the code. The problem is that the selected property name available via SortableDataProvider.getSort().getProperty() just returns the attribute name, and not whether it is a (derived|virtual) attribute. The SortableAttributableProviderComparator then calls: super.compare(new AttrModel(o1.getAttributeMap()), new AttrModel(o2.getAttributeMap())); As the selected attribute name is not in getAttributeMap(), but in getDerivedAttributeMap(), a NPE results. Two possible solutions: a) Record that the selected Attribute is derived or virtual when selected. Not too sure how to do this as there is only a getProperty() method available. b) Check to see if the selected property name is in the attributes map in SortableAttributableProviderComparator. If not then check derived, then virtual, etc. User List sorting via Derived attributes column doesn't work Key: SYNCOPE-332 URL: https://issues.apache.org/jira/browse/SYNCOPE-332 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5, 1.0.6, 1.1.0 Environment: OpenJDK JRE (IcedTea7 2.3.7); Tomcat7; Ubuntu Server 12.04 Reporter: Edward Siewick Priority: Trivial Labels: attributes, derived, list, sorting, user Fix For: 1.0.7, 1.1.0 User List sorting works for Attributes but not Derived attributes. These column headers can be selected; the presented URL is of the form similar to the Attributes columns. However, the refreshed page isn't sorted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-334) Can't delete a role from a user in the console
Colm O hEigeartaigh created SYNCOPE-334: --- Summary: Can't delete a role from a user in the console Key: SYNCOPE-334 URL: https://issues.apache.org/jira/browse/SYNCOPE-334 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 When trying to delete a Role from a User in the Console using the latest trunk code I get a Wicket error: ERROR: Wicket.Ajax.Call.processComponent: Component with id [[feedback25b]] was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. INFO: returned focused element: null INFO: Response processed successfully. INFO: refocus last focused component not needed/allowed INFO: Date pickers to delete=0, available=2 INFO: focus set on wicketDebugLink -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-334) Can't delete a role from a user in the console
[ https://issues.apache.org/jira/browse/SYNCOPE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-334: Priority: Minor (was: Major) Can't delete a role from a user in the console -- Key: SYNCOPE-334 URL: https://issues.apache.org/jira/browse/SYNCOPE-334 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.1.0 When trying to delete a Role from a User in the Console using the latest trunk code I get a Wicket error: ERROR: Wicket.Ajax.Call.processComponent: Component with id [[feedback25b]] was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. INFO: returned focused element: null INFO: Response processed successfully. INFO: refocus last focused component not needed/allowed INFO: Date pickers to delete=0, available=2 INFO: focus set on wicketDebugLink -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-334) Can't delete a role from a user in the console
[ https://issues.apache.org/jira/browse/SYNCOPE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592190#comment-13592190 ] Colm O hEigeartaigh commented on SYNCOPE-334: - Thanks! Colm. Can't delete a role from a user in the console -- Key: SYNCOPE-334 URL: https://issues.apache.org/jira/browse/SYNCOPE-334 Project: Syncope Issue Type: Bug Affects Versions: 1.1.0 Reporter: Colm O hEigeartaigh Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.1.0 When trying to delete a Role from a User in the Console using the latest trunk code I get a Wicket error: ERROR: Wicket.Ajax.Call.processComponent: Component with id [[feedback25b]] was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. INFO: returned focused element: null INFO: Response processed successfully. INFO: refocus last focused component not needed/allowed INFO: Date pickers to delete=0, available=2 INFO: focus set on wicketDebugLink -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-210) Provide suggestions / help / examples for JEXL-based input fields
[ https://issues.apache.org/jira/browse/SYNCOPE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601335#comment-13601335 ] Colm O hEigeartaigh commented on SYNCOPE-210: - Yup that works. So either we need to make the Mandatory Condition text field smaller (to the same size as name for example), or make the window wider. WDYT? Colm. Provide suggestions / help / examples for JEXL-based input fields - Key: SYNCOPE-210 URL: https://issues.apache.org/jira/browse/SYNCOPE-210 Project: Syncope Issue Type: Improvement Components: console Reporter: Francesco Chicchiriccò Assignee: Massimiliano Perrone Fix For: 1.1.0 Attachments: one.png, two.png There are many input text fields accepting JEXL syntax: * derived schema definition (user / role / membership) * values for defining synchronization user template * schema mapping's mandatory condition * ... Users would benefit from some examples, help, suggestions, link to JEXL reference to be displayed in (or linked from) the web forms containing such input fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-337) ClassNotFoundException in karaf osgi container
[ https://issues.apache.org/jira/browse/SYNCOPE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-337: Fix Version/s: (was: 1.1.1) ClassNotFoundException in karaf osgi container -- Key: SYNCOPE-337 URL: https://issues.apache.org/jira/browse/SYNCOPE-337 Project: Syncope Issue Type: Bug Components: console, core Affects Versions: 1.1.0 Environment: apache karaf 2.3.1 Reporter: Roman Minko Attachments: MANIFEST(console).MF, MANIFEST(core).MF Install war feature and try to install syncope core and console wars. Different dependencies issues and finally ClassNotFoundException in logs appeared. Syncope already include all the dependent jars in the lib/ folder of the war. But the MANIFEST files in the syncope-core and syncope-console are not correct enough, Bundle-ClassPath: , Web-ContextPath: should be added into MANIFEST. After manually adding Bundle-ClassPath: and update Import-Package: nothing dependencies bundles needed and no ClassNotFoundException. Pom files of core and console project should be updated to generate correct Bundle-ClassPath and Import-Package in MANIFEST. Or make changes on the MANIFEST directly during the build at least. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-337) ClassNotFoundException in karaf osgi container
[ https://issues.apache.org/jira/browse/SYNCOPE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645370#comment-13645370 ] Colm O hEigeartaigh commented on SYNCOPE-337: - Hi Francesco, Thanks for the hint. We're planning on revisiting this next week so hopefully we will fix this issue soon. Colm. ClassNotFoundException in karaf osgi container -- Key: SYNCOPE-337 URL: https://issues.apache.org/jira/browse/SYNCOPE-337 Project: Syncope Issue Type: Bug Components: console, core Affects Versions: 1.1.0 Environment: apache karaf 2.3.1 Reporter: Roman Minko Attachments: MANIFEST(console).MF, MANIFEST(core).MF Install war feature and try to install syncope core and console wars. Different dependencies issues and finally ClassNotFoundException in logs appeared. Syncope already include all the dependent jars in the lib/ folder of the war. But the MANIFEST files in the syncope-core and syncope-console are not correct enough, Bundle-ClassPath: , Web-ContextPath: should be added into MANIFEST. After manually adding Bundle-ClassPath: and update Import-Package: nothing dependencies bundles needed and no ClassNotFoundException. Pom files of core and console project should be updated to generate correct Bundle-ClassPath and Import-Package in MANIFEST. Or make changes on the MANIFEST directly during the build at least. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-337) ClassNotFoundException in karaf osgi container
[ https://issues.apache.org/jira/browse/SYNCOPE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-337: Fix Version/s: 1.2.0 ClassNotFoundException in karaf osgi container -- Key: SYNCOPE-337 URL: https://issues.apache.org/jira/browse/SYNCOPE-337 Project: Syncope Issue Type: Bug Components: console, core Affects Versions: 1.1.0 Environment: apache karaf 2.3.1 Reporter: Roman Minko Fix For: 1.2.0 Attachments: MANIFEST(console).MF, MANIFEST(core).MF Install war feature and try to install syncope core and console wars. Different dependencies issues and finally ClassNotFoundException in logs appeared. Syncope already include all the dependent jars in the lib/ folder of the war. But the MANIFEST files in the syncope-core and syncope-console are not correct enough, Bundle-ClassPath: , Web-ContextPath: should be added into MANIFEST. After manually adding Bundle-ClassPath: and update Import-Package: nothing dependencies bundles needed and no ClassNotFoundException. Pom files of core and console project should be updated to generate correct Bundle-ClassPath and Import-Package in MANIFEST. Or make changes on the MANIFEST directly during the build at least. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-372) Connector error before save
Colm O hEigeartaigh created SYNCOPE-372:
---
Summary: Connector error before save
Key: SYNCOPE-372
URL: https://issues.apache.org/jira/browse/SYNCOPE-372
Project: Syncope
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Colm O hEigeartaigh
Fix For: 1.1.2
There is an error in Syncope 1.1.1 when creating a new Connector. If you Check
Configuration before saving, you will get an error. The logs say:
SEVERE: Servlet.service() for servlet [syncope-core-rest] in context with path
[/syncope] threw exception [Request processing failed; nested exception is
org.apache.syncope.common.validation.SyncopeClientCompositeErrorException:
{[RequiredValuesMissing [connectorname]]}] with root cause
org.apache.syncope.common.validation.SyncopeClientCompositeErrorException:
{[RequiredValuesMissing [connectorname]]}
at
org.apache.syncope.core.rest.data.ConnInstanceDataBinder.getConnInstance(ConnInstanceDataBinder.java:83)
A valid name is present. If you click Save and then edit it again + try to
check the connection again, it works. I'm pretty sure this is a regression.
Confirmed with both the LDAP + DB Connectors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845239#comment-13845239
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi James,
Any update on some potential patches for this issue?
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (SYNCOPE-300) Supporting Feed Item Query Language (FIQL)
[ https://issues.apache.org/jira/browse/SYNCOPE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847632#comment-13847632 ] Colm O hEigeartaigh commented on SYNCOPE-300: - Hi Francesco, I've fixed CXF trunk + deployed a new build for you. Colm. Supporting Feed Item Query Language (FIQL) -- Key: SYNCOPE-300 URL: https://issues.apache.org/jira/browse/SYNCOPE-300 Project: Syncope Issue Type: Improvement Components: common, console, core Reporter: Jan Bernhardt Assignee: Francesco Chicchiriccò Priority: Minor Labels: feature Fix For: 1.2.0 Attachments: SYNCOPE-300.patch Currently search conditions are build using custom components (org.apache.syncope.common.search.*), goal of this issue is to replace current implementation with support for Supporting Feed Item Query Language (FIQL). For more details take a look at the discussion in development mailing list: http://syncope-dev.1063484.n5.nabble.com/DISCUSS-Feed-Item-Query-Language-td5712490.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (SYNCOPE-497) JEXL Frame positioning error
Colm O hEigeartaigh created SYNCOPE-497: --- Summary: JEXL Frame positioning error Key: SYNCOPE-497 URL: https://issues.apache.org/jira/browse/SYNCOPE-497 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.2.0 Attachments: jexl-error.png There is a problem with a JEXL frame positioning on trunk, where the help message does not appear properly on the screen (see attached png). Steps to reproduce: Tasks - Synchronization Task - Create User template Click on the help for Username. The result is the attached on both firefox and chrome. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-497) JEXL Frame positioning error
[ https://issues.apache.org/jira/browse/SYNCOPE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-497: Attachment: jexl-error.png JEXL Frame positioning error Key: SYNCOPE-497 URL: https://issues.apache.org/jira/browse/SYNCOPE-497 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.2.0 Attachments: jexl-error.png There is a problem with a JEXL frame positioning on trunk, where the help message does not appear properly on the screen (see attached png). Steps to reproduce: Tasks - Synchronization Task - Create User template Click on the help for Username. The result is the attached on both firefox and chrome. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-497) JEXL Frame positioning error
[ https://issues.apache.org/jira/browse/SYNCOPE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013491#comment-14013491 ] Colm O hEigeartaigh commented on SYNCOPE-497: - Well it's quite trivial :-) However the message should appear without the user having to scroll to read it. Colm. JEXL Frame positioning error Key: SYNCOPE-497 URL: https://issues.apache.org/jira/browse/SYNCOPE-497 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.2.0 Attachments: jexl-error.png There is a problem with a JEXL frame positioning on trunk, where the help message does not appear properly on the screen (see attached png). Steps to reproduce: Tasks - Synchronization Task - Create User template Click on the help for Username. The result is the attached on both firefox and chrome. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SYNCOPE-498) Connector SpinnerFieldPanel required values
Colm O hEigeartaigh created SYNCOPE-498: --- Summary: Connector SpinnerFieldPanel required values Key: SYNCOPE-498 URL: https://issues.apache.org/jira/browse/SYNCOPE-498 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.2.0 With the latest Syncope trunk code, I noticed that if I create a new LDAP Connector (1.3.6) it appears to be requiring me to enter a Block Size + Change Log Block Size, even though these parameters are optional and both default to 100. You can reproduce by just creating an LDAP Connector + clicking on save. At the top of the screen you can see: 'Host' is required. 'TCP Port' is required. 'Base Contexts' is required. 'Block Size' is required. 'Change Log Block Size' is required. The issue seems to be related to the new component SpinnerFieldPanel used to represents numeric connector configuration properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-498) Connector SpinnerFieldPanel required values
[ https://issues.apache.org/jira/browse/SYNCOPE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017607#comment-14017607 ] Colm O hEigeartaigh commented on SYNCOPE-498: - Fix confirmed, thanks! Colm. Connector SpinnerFieldPanel required values --- Key: SYNCOPE-498 URL: https://issues.apache.org/jira/browse/SYNCOPE-498 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.2.0 With the latest Syncope trunk code, I noticed that if I create a new LDAP Connector (1.3.6) it appears to be requiring me to enter a Block Size + Change Log Block Size, even though these parameters are optional and both default to 100. You can reproduce by just creating an LDAP Connector + clicking on save. At the top of the screen you can see: 'Host' is required. 'TCP Port' is required. 'Base Contexts' is required. 'Block Size' is required. 'Change Log Block Size' is required. The issue seems to be related to the new component SpinnerFieldPanel used to represents numeric connector configuration properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-497) JEXL Frame positioning error
[ https://issues.apache.org/jira/browse/SYNCOPE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019884#comment-14019884 ] Colm O hEigeartaigh commented on SYNCOPE-497: - Thanks, looks good. Colm. JEXL Frame positioning error Key: SYNCOPE-497 URL: https://issues.apache.org/jira/browse/SYNCOPE-497 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Assignee: Marco Di Sabatino Di Diodoro Priority: Minor Fix For: 1.2.0 Attachments: jexl-error.png There is a problem with a JEXL frame positioning on trunk, where the help message does not appear properly on the screen (see attached png). Steps to reproduce: Tasks - Synchronization Task - Create User template Click on the help for Username. The result is the attached on both firefox and chrome. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019961#comment-14019961
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi all,
I'm just starting to look into this topic again. Here is an initial proposal,
feedback welcome!
- A current limitation of Syncope is that password encoding (when digesting)
is hardcoded to HEX in PasswordEncoder. I propose that this should be
configurable (password.cipher.encoding or something) so that we can also
support BASE-64 encoding.
- A new Connector property for the relevant connectors is added to specify
whether the password is encoded in either HEX or BASE-64.
- Let's assume we are dealing with LDAP where we might have passwords encoded
in the form {sha}XYZ=, or they could be in plaintext. On synchronization, if
it doesn't start with {hash-alg} then we treat it as plaintext, and hash
according to the default value + encode according to the default value. If it
does start with {hash-alg}, the cipherAlgorithm parameter of a SyncopeUser
will get populated by the hash algorithm specified in the password first, and
fall back to the default value if it doesn't exist. SyncopeUser will also have
a password encoding value derived from the Connector, which will also fall back
to the default value. In this case (hashed password), we do not explicitly
encode the password via PasswordEncoder, but just use the value we receive
(minus the {hash-alg} prefix).
- For a SQL table, we will have to add a new hash algorithm parameter, so that
we know that the values received are hashed + that we can treat them as such.
Does this broadly make sense or is there a better way? If the former, then I
will start looking into how this will actually work without polluting the
SyncopeSyncResultHandler will Connector-specific stuff.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021866#comment-14021866
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi Francesco,
That sounds reasonable to me. Two questions though:
a) By synchronization actions are you referring to the existing Actions class
that you can select in the Resource configuration? (e.g.
LDAPMembershipPropagationAction), or something new that would be associated
with the Connector itself?
b) We still have the problem with BASE-64/HEX encoding that I raised. What do
you think of my first two points?
Thanks,
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026295#comment-14026295
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi Francesco,
Ok thanks for the clarification. I think allowing a list of propagation + sync
actions makes sense, so that we could support the new password + membership
sync actions behaviours at the same time, for example.
To clarify the password encoding issue: Currently, the PasswordEncoder
hard-codes the digest output to HEX:
digester.setStringOutputType(CommonUtils.STRING_OUTPUT_TYPE_HEXADECIMAL);
So let's say our LDAPPasswordSynchronizationAction is taking the encoded
password + setting it directly into SyncopeUser. For the LDAP example, it is
BASE-64 encoded. However, when we try to verify a password next, we end up
comparing a BASE-64 encoded digest stored in SyncopeUser with the HEX encoded
digest generated in PasswordEncoder.verify.
Does that make sense?
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026321#comment-14026321
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
The user password that is encoded currently in PasswordEncoder.encode is of the
form {SHA}XYZ= for the LDAP use-case. It appears that the password is just
imported as is. Note that I am not using the password synchronization
feature of the LDAP Connector, just ticking the retrieve passwords checkbox.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026407#comment-14026407
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Ok so what you are proposing is that we BASE-64 decode the encoded password in
LDAPPasswordSyncAction, and then HEX encode it + store it in SyncopeUser? Yes I
think this will work fine. The only issue is that it seems a bit unwieldy to
have separate Sync Actions just to support different encoding behaviours. I
guess we could just default to assuming the passwords are BASE-64 encoded in
the backend for now.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026419#comment-14026419
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form {SHA}XYZ, it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form {SHA}XYZ, then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
Does this cover it?
Colm.
b) SYNCOPE-502
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026419#comment-14026419
]
Colm O hEigeartaigh edited comment on SYNCOPE-313 at 6/10/14 1:14 PM:
--
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form {SHA}XYZ, it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form {SHA}XYZ, then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
d) SYNCOPE-502 will provider for chaining multiple action classes together if
required.
Does this cover it?
Colm.
was (Author: coheigea):
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form {SHA}XYZ, it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form {SHA}XYZ, then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
Does this cover it?
Colm.
b) SYNCOPE-502
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026427#comment-14026427
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Sounds good!
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029194#comment-14029194
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi Francesco,
any particular reason why not to replace SHA1(SHA-1, false) with
SHA(SHA-1, false)?
I just left SHA1 there for backwards compatibility reasons, so that a value of
SHA1 as part of the password cipher algorithm would still work. I don't see
any harm in having both SHA + SHA1 map to the same thing.
the last argument in SyncopeUser#setEncodedPassword looks not-needed: correct?
Yep.
What do you think about backporting the SyncopeUser + CipherAlgorithm changes
(just the SHA addition) to 1.1.x? At least then a user could plug in their own
SyncActions implementation to support this behaviour if required.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved SYNCOPE-313.
-
Resolution: Fixed
Tested both LDAP + DB SyncActions properly.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned SYNCOPE-505:
---
Assignee: Colm O hEigeartaigh
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030710#comment-14030710
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
Hi Francesco,
I'm just wondering what the use-case is here: Is it when we have users
synchronized into Syncope from one resource with non-cleartext passwords, that
we then want to propagate to another resource? When we create users in Syncope,
then we can just propagate out the password hashed according to the connector
property, right?
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033813#comment-14033813
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
I added an initial prototype implementation for DBPasswordPropagationActions.
It checks to see if there is a mandatory missing attribute that corresponds to
password, and then just writes out the password from SyncopeUser as is in
this case. What do you think about this approach?
I've tested the prototype + it works. One issue is that it only works if the
Connector uses CLEARTEXT, as otherwise the supplied password gets hashed.
Should we add another Connector property so that we can tell it to only
hash/encrypt if the supplied password is plaintext?
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033918#comment-14033918
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
{quote}
We should find a way then to instruct the connector that the specific password
value we are passing is already hashed: unfortunately, connector configuration
properties are only evaluated when creating a connector instance, so they
cannot be changed on-the-fly.
{quote}
Could we have a new (boolean) attribute (__HASHED_PASSWORD__) or something?
Alternatively, we could use a predefined prefix/suffix on the _PASSWORD_. Any
preferences?
{quote}
BTW, writing out the password only if SyncopeUser#getCipherAlgorithm matches
the configured value for the DB Connector hash algorithm (e.g. the same logic
of SYNCOPE-313) seems correct to me.
{quote}
Ok, sounds good. One query would be whether we should also follow this logic if
the DB Connector has a CLEARTEXT value? I think we should, but want to verify
it.
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033936#comment-14033936
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
{quote}
A special _HASHED_PASSWORD_ boolean attribute - defaults to true when missing -
could be added to the DBTable connector configuration: sounds good.
{quote}
Shouldn't it default to false when missing? I.e. _HASHED_PASSWORD_ being
present and true means that the value under _PASSWORD_ should be treated as
hashed + not subsequently hashed with the configured Connector hash algorithm.
Otherwise, the Connector hash algorithm applies.
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037181#comment-14037181
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
{quote}
BTW, writing out the password only if SyncopeUser#getCipherAlgorithm matches
the configured value for the DB Connector hash algorithm (e.g. the same logic
of SYNCOPE-313) seems correct to me.
{quote}
A quick query on this - in DBPasswordSyncActions I can get access to the
Connector via
AbstractSyncopeResultHandler.getConnector().getActiveConnInstance(). How can I
do the same in DBPasswordPropagationActions?
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040896#comment-14040896
]
Colm O hEigeartaigh commented on SYNCOPE-505:
-
Hi Francesco,
I have this working for LDAP as well but wanted to validate my approach.
For the DB Connector we are sending an extra attribute over to tell the
Connector that the password is already hashed. For LDAP, we could do this as
well, but I implemented the reverse of the Sync Action. So if the configured
cipher algorithm of the user matches that of the LDAP Connector, it takes the
user password, de-hexes it + Base64 encodes it. It then writes out the same
type of value that it syncs, i.e. {sha}XYZ...==.
The LDAP Connector needs a change to detect a password of this form { +
matching digest + } + rest-of-password, and if so it simply stores the
received password as is.
WDYT?
Colm.
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-516) Binary Schema UI enhancements
[ https://issues.apache.org/jira/browse/SYNCOPE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042136#comment-14042136 ] Colm O hEigeartaigh commented on SYNCOPE-516: - The byte count is probably not necessary IMO, if the third point allows for a simple way to see whether an attribute has a value or not. Colm. Binary Schema UI enhancements - Key: SYNCOPE-516 URL: https://issues.apache.org/jira/browse/SYNCOPE-516 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.2.0 Reporter: Andrea Patricelli Assignee: Andrea Patricelli Fix For: 1.2.0 Binary schema enhancements: 1) Change text field to auto-complete text field to allow user to write whatever MIME type, but he has also the support of a complete and updated list of suggestions. 2) Display total byte count of the attribute in User UI. 3) Provide a pluggable binary viewer mechanism (as discussed in [1]) [1] http://syncope-user.1051894.n5.nabble.com/Certificates-in-Syncope-td5706704.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-516) Binary Schema UI enhancements
[ https://issues.apache.org/jira/browse/SYNCOPE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042209#comment-14042209 ] Colm O hEigeartaigh commented on SYNCOPE-516: - Yes that makes sense I think! Colm. Binary Schema UI enhancements - Key: SYNCOPE-516 URL: https://issues.apache.org/jira/browse/SYNCOPE-516 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.2.0 Reporter: Andrea Patricelli Assignee: Andrea Patricelli Fix For: 1.2.0 Binary schema enhancements: 1) Change text field to auto-complete text field to allow user to write whatever MIME type, but he has also the support of a complete and updated list of suggestions. 2) Display total byte count of the attribute in User UI. 3) Provide a pluggable binary viewer mechanism (as discussed in [1]) [1] http://syncope-user.1051894.n5.nabble.com/Certificates-in-Syncope-td5706704.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043267#comment-14043267 ] Colm O hEigeartaigh commented on SYNCOPE-164: - Hi Francesco, I'm wondering if this task might be somewhat straightforward enough to implement for 1.2... If user authentication fails in the SyncopeAuthenticationProvider + if pass through authentication is enabled via a resource property / account policy / etc., then grab the Connectors associated with the user + try to perform authentication using the supplied credentials. Or am I missing something? Colm. Passthrough authentication -- Key: SYNCOPE-164 URL: https://issues.apache.org/jira/browse/SYNCOPE-164 Project: Syncope Issue Type: Sub-task Reporter: Francesco Chicchiriccò Fix For: 3.0.0 Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved SYNCOPE-505.
-
Resolution: Fixed
Support propagating non-cleartext passwords to external resources
-
Key: SYNCOPE-505
URL: https://issues.apache.org/jira/browse/SYNCOPE-505
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Francesco Chicchiriccò
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
{{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
values to external resources.
This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-164: --- Assignee: Colm O hEigeartaigh Passthrough authentication -- Key: SYNCOPE-164 URL: https://issues.apache.org/jira/browse/SYNCOPE-164 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Assignee: Colm O hEigeartaigh Fix For: 1.2.0 Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-513) Make value encryption parametric
[
https://issues.apache.org/jira/browse/SYNCOPE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043460#comment-14043460
]
Colm O hEigeartaigh commented on SYNCOPE-513:
-
I can take this on, unless someone else wants to fix it?
Colm.
Make value encryption parametric
Key: SYNCOPE-513
URL: https://issues.apache.org/jira/browse/SYNCOPE-513
Project: Syncope
Issue Type: Improvement
Components: core
Affects Versions: 1.1.8
Reporter: Yann Diorcet
Fix For: 1.2.0
In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt
mechanism configuration is hardcoded
If the LDAP server doesn't use the same salt mechanism configuration, the
password can't be matched during authentication.
For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
plan)
Original:
{code}
digester.setIterations(10);
digester.setSaltSizeBytes(16);
{code}
Modified for OpenDJ:
{code}
digester.setIterations(1);
digester.setSaltSizeBytes(8);
digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
{code}
{{Encryptor}} can read from global configuration parameters so that you can
configure some aspect of the way how ciphered values (not only password
values in 1.2.X).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-164: Assignee: (was: Colm O hEigeartaigh) Passthrough authentication -- Key: SYNCOPE-164 URL: https://issues.apache.org/jira/browse/SYNCOPE-164 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Fix For: 1.2.0 Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045973#comment-14045973 ] Colm O hEigeartaigh commented on SYNCOPE-164: - It sounds reasonable to me... Colm. Passthrough authentication -- Key: SYNCOPE-164 URL: https://issues.apache.org/jira/browse/SYNCOPE-164 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.2.0 Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-516) Binary Schema UI enhancements
[ https://issues.apache.org/jira/browse/SYNCOPE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047699#comment-14047699 ] Colm O hEigeartaigh commented on SYNCOPE-516: - Nice work! Colm. Binary Schema UI enhancements - Key: SYNCOPE-516 URL: https://issues.apache.org/jira/browse/SYNCOPE-516 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.2.0 Reporter: Andrea Patricelli Assignee: Andrea Patricelli Fix For: 1.2.0 Binary schema enhancements: 1) Change text field to auto-complete text field to allow user to write whatever MIME type, but he has also the support of a complete and updated list of suggestions. 2) Display whether attribute has value or not, working on download arrow opacity. 3) Provide a pluggable binary viewer mechanism (as discussed in [1]) [1] http://syncope-user.1051894.n5.nabble.com/Certificates-in-Syncope-td5706704.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-516) Binary Schema UI enhancements
[ https://issues.apache.org/jira/browse/SYNCOPE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047702#comment-14047702 ] Colm O hEigeartaigh commented on SYNCOPE-516: - applicaiton/x-bytecode.python...spelling mistake here? Colm. Binary Schema UI enhancements - Key: SYNCOPE-516 URL: https://issues.apache.org/jira/browse/SYNCOPE-516 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.2.0 Reporter: Andrea Patricelli Assignee: Andrea Patricelli Fix For: 1.2.0 Binary schema enhancements: 1) Change text field to auto-complete text field to allow user to write whatever MIME type, but he has also the support of a complete and updated list of suggestions. 2) Display whether attribute has value or not, working on download arrow opacity. 3) Provide a pluggable binary viewer mechanism (as discussed in [1]) [1] http://syncope-user.1051894.n5.nabble.com/Certificates-in-Syncope-td5706704.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048797#comment-14048797
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Integration tests merged for SYNCOPE-505. Is there any example of a SyncTask
executing successfully in the integration test-code? The idea I had was to
extend the tests in SYNCOPE-505, by changing the local password, and then
sync'ing from the resource again + checking the password was changed. When I
add a SyncTask via something like this, it doesn't seem to have fired (in
time?) and the user is not updated:
SyncTaskTO syncTask = new SyncTaskTO();
syncTask.setName(DB Sync Task);
syncTask.setDescription(DB Sync Task description);
syncTask.setPerformCreate(true);
syncTask.setPerformUpdate(true);
syncTask.setFullReconciliation(true);
syncTask.setResource(RESOURCE_NAME_TESTDB);
syncTask.setStartDate(new Date());
syncTask.getActionsClassNames().add(DBPasswordSyncActions.class.getName());
Response taskResponse = taskService.create(syncTask);
String taskId = taskResponse.getHeaderString(RESTHeaders.RESOURCE_ID);
TaskExecTO taskExec = taskService.execute(Long.valueOf(taskId), false);
Any ideas?
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048911#comment-14048911 ] Colm O hEigeartaigh commented on SYNCOPE-164: - Hi Francesco, I just experimented a bit with this feature, by syncing in some users from LDAP and not providing a password mapping. I can log on via the REST API fine when the user has either a plaintext, SHA or SSHA password in LDAP. However authentication doesn't seem to work when the user has a SHA-256 password. Is the global user cipher algorithm, or the password digest algorithm of the Connector in play here? Thanks, Colm. Passthrough authentication -- Key: SYNCOPE-164 URL: https://issues.apache.org/jira/browse/SYNCOPE-164 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.2.0 Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050314#comment-14050314
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Tests committed. I @Ignore'd the LDAP test, as it seems to be causing a
side-effect on reconcileFromLDAP for some reason.
Colm.
Support synchronizing non-cleartext passwords from external resources
-
Key: SYNCOPE-313
URL: https://issues.apache.org/jira/browse/SYNCOPE-313
Project: Syncope
Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.2.0
Currently we can synchronize cleartext passwords from external resources.
However, we can't handle non-cleartext passwords, as they get treated as if
they are plaintext passwords when imported into Syncope, and hence hashed
again according to user.cipherAlgorithm().
This task is to treat an imported password as hashed according to a give
cipher algorithm configured on the connector (for example via 'Password
Cipher Algorithm' for the DB Connector).
This is specific to each individual connector, as for example for the DB
Connector, it might just be a hashed value stored in a table, whereas for
LDAP it'll be of the form CIPHER}VALUE etc.
Note that we we cannot refer to any specific connector bundle from inside the
SyncopeSyncResultHandler, hence we should find the cleanest place to
encapsulate the following logic:
if (password.isClearText()) {
// do as currently done
} else {
if (connector.isLDAP()) {
// extract cipher and value
} else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
} else {
...
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-143) GUI Installer
[ https://issues.apache.org/jira/browse/SYNCOPE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130089#comment-14130089 ] Colm O hEigeartaigh commented on SYNCOPE-143: - Any comments on my queries? :-) Colm. GUI Installer - Key: SYNCOPE-143 URL: https://issues.apache.org/jira/browse/SYNCOPE-143 Project: Syncope Issue Type: New Feature Components: installer Reporter: Francesco Chicchiriccò Assignee: Massimiliano Perrone Fix For: 1.2.0 Attachments: installer-improvements.patch Provide a web interface that will help users configuring an initial setup. Relevant discussion: http://markmail.org/message/j36i55z7weiqt2sw -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-143) GUI Installer
[ https://issues.apache.org/jira/browse/SYNCOPE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14133998#comment-14133998 ] Colm O hEigeartaigh commented on SYNCOPE-143: - Looks good, thanks Andrea! WRT: 1) for the maven home directory property the problem is on windows environment we have to specify it! I have not found an alternative way :/ Yep, but at least querying M2_HOME would work on linux :-) It's pretty simple, just check to see whether the system property is valid or not + if so just use it as the default field value...wdyt? Colm. GUI Installer - Key: SYNCOPE-143 URL: https://issues.apache.org/jira/browse/SYNCOPE-143 Project: Syncope Issue Type: New Feature Components: installer Reporter: Francesco Chicchiriccò Assignee: Massimiliano Perrone Fix For: 1.2.0 Attachments: installer-improvements.patch Provide a web interface that will help users configuring an initial setup. Relevant discussion: http://markmail.org/message/j36i55z7weiqt2sw -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-143) GUI Installer
[ https://issues.apache.org/jira/browse/SYNCOPE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134058#comment-14134058 ] Colm O hEigeartaigh commented on SYNCOPE-143: - One thing I've noticed is that the Syncope install doesn't have any account/password/synchronization policies. Does it make sense to have sensible default policies installed? Colm. GUI Installer - Key: SYNCOPE-143 URL: https://issues.apache.org/jira/browse/SYNCOPE-143 Project: Syncope Issue Type: New Feature Components: installer Reporter: Francesco Chicchiriccò Assignee: Massimiliano Perrone Fix For: 1.2.0 Attachments: installer-improvements.patch Provide a web interface that will help users configuring an initial setup. Relevant discussion: http://markmail.org/message/j36i55z7weiqt2sw -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-610) Installer doesn't update the console.properties with the container port
Colm O hEigeartaigh created SYNCOPE-610: --- Summary: Installer doesn't update the console.properties with the container port Key: SYNCOPE-610 URL: https://issues.apache.org/jira/browse/SYNCOPE-610 Project: Syncope Issue Type: Bug Components: installer Affects Versions: 1.2.1 Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 1.2.2 When installing Syncope via the installer to Tomcat, if you change the port it isn't reflected in the resulting syncope-console/WEB-INF/classes/console.properties. Possibly the host needs to be changed as well as part of this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-722) CLI documentation
[ https://issues.apache.org/jira/browse/SYNCOPE-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038129#comment-15038129 ] Colm O hEigeartaigh commented on SYNCOPE-722: - Sure, I've just merged some minor fixes. Well done on writing the documentation, it is quite comprehensive! Colm. > CLI documentation > - > > Key: SYNCOPE-722 > URL: https://issues.apache.org/jira/browse/SYNCOPE-722 > Project: Syncope > Issue Type: Sub-task > Components: cli, documentation >Reporter: Massimiliano Perrone >Assignee: Massimiliano Perrone > Fix For: 2.0.0 > > > Provide documentation about CLI component -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-875) Can't test LDAP Connector in admin console
[ https://issues.apache.org/jira/browse/SYNCOPE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-875: Attachment: syncope-connectorname-error.png > Can't test LDAP Connector in admin console > -- > > Key: SYNCOPE-875 > URL: https://issues.apache.org/jira/browse/SYNCOPE-875 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.0-M3 >Reporter: Colm O hEigeartaigh > Fix For: 2.0.0 > > Attachments: syncope-connectorname-error.png > > > I'm seeing an error when trying to test an LDAP Connector with 2.0.0-M3: > "Connection failure: RequiredValuesMissing [connectorname]" > From the logs, I can see that the connector name is null: > 16:11:20.054 ERROR org.apache.syncope.client.console.rest.BaseRestClient - > While checking org.apache.syncope.common.lib.to.ConnInstanceTO@548806e8[ > key= > location=connid://testconnectorserver@localhost:4554 > connectorName= > bundleName=net.tirasa.connid.bundles.ldap > version=1.5.1 > conf=[org.apache.syncope.common.lib.types.ConnConfProperty@1dc08e5[ > schema=org.apache.syncope.common.lib.types.ConnConfPropSchema@3a2f6f01[ > name=groupMemberAttribute > displayName=Group Member Attribute -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-875) Can't test LDAP Connector in admin console
Colm O hEigeartaigh created SYNCOPE-875: --- Summary: Can't test LDAP Connector in admin console Key: SYNCOPE-875 URL: https://issues.apache.org/jira/browse/SYNCOPE-875 Project: Syncope Issue Type: Bug Affects Versions: 2.0.0-M3 Reporter: Colm O hEigeartaigh Fix For: 2.0.0 Attachments: syncope-connectorname-error.png I'm seeing an error when trying to test an LDAP Connector with 2.0.0-M3: "Connection failure: RequiredValuesMissing [connectorname]" >From the logs, I can see that the connector name is null: 16:11:20.054 ERROR org.apache.syncope.client.console.rest.BaseRestClient - While checking org.apache.syncope.common.lib.to.ConnInstanceTO@548806e8[ key= location=connid://testconnectorserver@localhost:4554 connectorName= bundleName=net.tirasa.connid.bundles.ldap version=1.5.1 conf=[org.apache.syncope.common.lib.types.ConnConfProperty@1dc08e5[ schema=org.apache.syncope.common.lib.types.ConnConfPropSchema@3a2f6f01[ name=groupMemberAttribute displayName=Group Member Attribute -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-878) Failure on bulk deletion of users
[ https://issues.apache.org/jira/browse/SYNCOPE-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-878: Attachment: syncope-re.png > Failure on bulk deletion of users > - > > Key: SYNCOPE-878 > URL: https://issues.apache.org/jira/browse/SYNCOPE-878 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.0-M4 >Reporter: Colm O hEigeartaigh > Fix For: 2.0.0 > > Attachments: syncope-re.png > > > When I try to bulk delete the users in the standalone distribution for > 2.0.0-M4, it fails on one of the users. Then when I click "close" on the > deletion box, the console errors with a RuntimeException (see attached > screenshot). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-878) Failure on bulk deletion of users
Colm O hEigeartaigh created SYNCOPE-878: --- Summary: Failure on bulk deletion of users Key: SYNCOPE-878 URL: https://issues.apache.org/jira/browse/SYNCOPE-878 Project: Syncope Issue Type: Bug Affects Versions: 2.0.0-M4 Reporter: Colm O hEigeartaigh Fix For: 2.0.0 When I try to bulk delete the users in the standalone distribution for 2.0.0-M4, it fails on one of the users. Then when I click "close" on the deletion box, the console errors with a RuntimeException (see attached screenshot). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-824) Push/Pull task "names" not marked as mandatory in the console
Colm O hEigeartaigh created SYNCOPE-824:
---
Summary: Push/Pull task "names" not marked as mandatory in the
console
Key: SYNCOPE-824
URL: https://issues.apache.org/jira/browse/SYNCOPE-824
Project: Syncope
Issue Type: Improvement
Components: console
Affects Versions: 2.0.0-M2
Reporter: Colm O hEigeartaigh
Priority: Minor
Fix For: 2.0.0
When creating a push/pull task in the console, there is no "*" beside the
"name" indicating it is mandatory. You can click "Next" to go to the next
screen, but you only see an error on "Finish":
InvalidSchedTask [Standard: {javax.validation.constraints.NotNull.message}]
I think the Destination Realm + Pull Mode should also be marked mandatory for
the pull task.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SYNCOPE-791) Update UI to display what you're adding when creating a role
[ https://issues.apache.org/jira/browse/SYNCOPE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-791: Fix Version/s: 2.0.0 > Update UI to display what you're adding when creating a role > > > Key: SYNCOPE-791 > URL: https://issues.apache.org/jira/browse/SYNCOPE-791 > Project: Syncope > Issue Type: Improvement >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: role-entitlements.png > > > When creating a new role in 2.0.0-M2, it isn't immediately obvious to a > novice user when asked to select items that it is referring to entitlements > and realms. See the attached screenshot for reference. I think the UI should > be updated to display "Select entitlements", "Select realms" or something > similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-791) Update UI to display what you're adding when creating a role
Colm O hEigeartaigh created SYNCOPE-791: --- Summary: Update UI to display what you're adding when creating a role Key: SYNCOPE-791 URL: https://issues.apache.org/jira/browse/SYNCOPE-791 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Priority: Minor When creating a new role in 2.0.0-M2, it isn't immediately obvious to a novice user when asked to select items that it is referring to entitlements and realms. See the attached screenshot for reference. I think the UI should be updated to display "Select entitlements", "Select realms" or something similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-791) Update UI to display what you're adding when creating a role
[ https://issues.apache.org/jira/browse/SYNCOPE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-791: Attachment: role-entitlements.png > Update UI to display what you're adding when creating a role > > > Key: SYNCOPE-791 > URL: https://issues.apache.org/jira/browse/SYNCOPE-791 > Project: Syncope > Issue Type: Improvement >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: role-entitlements.png > > > When creating a new role in 2.0.0-M2, it isn't immediately obvious to a > novice user when asked to select items that it is referring to entitlements > and realms. See the attached screenshot for reference. I think the UI should > be updated to display "Select entitlements", "Select realms" or something > similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-791) Update UI to display what you're adding when creating a role
[ https://issues.apache.org/jira/browse/SYNCOPE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-791: Affects Version/s: 2.0.0-M2 > Update UI to display what you're adding when creating a role > > > Key: SYNCOPE-791 > URL: https://issues.apache.org/jira/browse/SYNCOPE-791 > Project: Syncope > Issue Type: Improvement >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: role-entitlements.png > > > When creating a new role in 2.0.0-M2, it isn't immediately obvious to a > novice user when asked to select items that it is referring to entitlements > and realms. See the attached screenshot for reference. I think the UI should > be updated to display "Select entitlements", "Select realms" or something > similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-792) Improve JEXL information text for "mandatory" when creating a new schema attribute
[ https://issues.apache.org/jira/browse/SYNCOPE-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-792: Attachment: syncope-mandatory.png > Improve JEXL information text for "mandatory" when creating a new schema > attribute > -- > > Key: SYNCOPE-792 > URL: https://issues.apache.org/jira/browse/SYNCOPE-792 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-mandatory.png > > > When creating a new Schema attribute, and clicking on the information "i" > button, the information that appears about JEXL expressions is a bit > confusing, as it's not obvious how "surname" and "firstname" relate to > "mandatory". This task should be to update the information to be relevant to > the "mandatory" tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-792) Improve JEXL information text for "mandatory" when creating a new schema attribute
Colm O hEigeartaigh created SYNCOPE-792: --- Summary: Improve JEXL information text for "mandatory" when creating a new schema attribute Key: SYNCOPE-792 URL: https://issues.apache.org/jira/browse/SYNCOPE-792 Project: Syncope Issue Type: Bug Components: console Affects Versions: 2.0.0-M2 Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.0 Attachments: syncope-mandatory.png When creating a new Schema attribute, and clicking on the information "i" button, the information that appears about JEXL expressions is a bit confusing, as it's not obvious how "surname" and "firstname" relate to "mandatory". This task should be to update the information to be relevant to the "mandatory" tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-791) Update UI to display what you're adding when creating a role
[ https://issues.apache.org/jira/browse/SYNCOPE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-791: Component/s: console > Update UI to display what you're adding when creating a role > > > Key: SYNCOPE-791 > URL: https://issues.apache.org/jira/browse/SYNCOPE-791 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: role-entitlements.png > > > When creating a new role in 2.0.0-M2, it isn't immediately obvious to a > novice user when asked to select items that it is referring to entitlements > and realms. See the attached screenshot for reference. I think the UI should > be updated to display "Select entitlements", "Select realms" or something > similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-794) UI is insisting on an external attribute for AccountId
[ https://issues.apache.org/jira/browse/SYNCOPE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206559#comment-15206559 ] Colm O hEigeartaigh commented on SYNCOPE-794: - Is there a workaround for this - something to specify for the external attribute? Colm. > UI is insisting on an external attribute for AccountId > -- > > Key: SYNCOPE-794 > URL: https://issues.apache.org/jira/browse/SYNCOPE-794 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: resource-external-attr.png > > > When trying to add a new user mapping from the internal "Username" to the > remote AccountId, it appears that Syncope is insisting that an external > attribute must be specified. In previous Syncope versions, once the AccountId > was checked, the external attribute textbox was grayed out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-805) Select destination realm from a drop down list when creating a task
[ https://issues.apache.org/jira/browse/SYNCOPE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-805: Description: When creating a (pull) task, if you have to explicitly specify the realm. However, a better idea would be if the user could select the realm from a dropdown list. Incidentally, when currently creating a pull task, if you fail to specify the realm you get an error message: org.apache.syncope.common.lib.SyncopeClientException: InvalidPath [MalformedPathException: Malformed path: null] This should be updated to let the user know the realm needs to be specified. But this is probably not required if the user has to select the realm from a list. was: When creating a pull task, if you fail to specify the realm you get an error message: org.apache.syncope.common.lib.SyncopeClientException: InvalidPath [MalformedPathException: Malformed path: null] This should be updated to let the user know the realm needs to be specified. Issue Type: Improvement (was: Bug) Summary: Select destination realm from a drop down list when creating a task (was: Unhelpful error message when a realm is not specified in a pull task) > Select destination realm from a drop down list when creating a task > --- > > Key: SYNCOPE-805 > URL: https://issues.apache.org/jira/browse/SYNCOPE-805 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > > When creating a (pull) task, if you have to explicitly specify the realm. > However, a better idea would be if the user could select the realm from a > dropdown list. > Incidentally, when currently creating a pull task, if you fail to specify the > realm you get an error message: > org.apache.syncope.common.lib.SyncopeClientException: InvalidPath > [MalformedPathException: Malformed path: null] > This should be updated to let the user know the realm needs to be specified. > But this is probably not required if the user has to select the realm from a > list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-811) Error message "'spinner' is required"
[ https://issues.apache.org/jira/browse/SYNCOPE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-811: Attachment: syncope-spinner.png > Error message "'spinner' is required" > - > > Key: SYNCOPE-811 > URL: https://issues.apache.org/jira/browse/SYNCOPE-811 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-spinner.png > > > If you don't specify a value when configuring a Group for a required (int) > parameter, you get a generic error message "'spinner' is required". Instead, > the error message should display the name of the parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-811) Error message "'spinner' is required"
Colm O hEigeartaigh created SYNCOPE-811: --- Summary: Error message "'spinner' is required" Key: SYNCOPE-811 URL: https://issues.apache.org/jira/browse/SYNCOPE-811 Project: Syncope Issue Type: Bug Components: console Affects Versions: 2.0.0-M2 Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.0 Attachments: syncope-spinner.png If you don't specify a value when configuring a Group for a required (int) parameter, you get a generic error message "'spinner' is required". Instead, the error message should display the name of the parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-813) Remove "mandatory" field from configuration parameter creation
Colm O hEigeartaigh created SYNCOPE-813: --- Summary: Remove "mandatory" field from configuration parameter creation Key: SYNCOPE-813 URL: https://issues.apache.org/jira/browse/SYNCOPE-813 Project: Syncope Issue Type: Bug Components: console Affects Versions: 2.0.0-M2 Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.0 This task is to remove the "mandatory" field from the Configuration Parameter creation page, as Configuration Parameters are optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-813) Remove "mandatory" field from configuration parameter creation
[ https://issues.apache.org/jira/browse/SYNCOPE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-813: Description: This task is to remove the "mandatory" field from the Configuration Parameter creation page, as Configuration Parameters are optional. Also, remove from sample configuration (e.g. in MasterContent.xml): was: This task is to remove the "mandatory" field from the Configuration Parameter creation page, as Configuration Parameters are optional. > Remove "mandatory" field from configuration parameter creation > -- > > Key: SYNCOPE-813 > URL: https://issues.apache.org/jira/browse/SYNCOPE-813 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > > This task is to remove the "mandatory" field from the Configuration Parameter > creation page, as Configuration Parameters are optional. Also, remove from > sample configuration (e.g. in MasterContent.xml): > mandatoryCondition="true" multivalue="1" uniqueConstraint="0" > readonly="0"/> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SYNCOPE-814) MasterContent.xml configuration is broken for "main"
Colm O hEigeartaigh created SYNCOPE-814: --- Summary: MasterContent.xml configuration is broken for "main" Key: SYNCOPE-814 URL: https://issues.apache.org/jira/browse/SYNCOPE-814 Project: Syncope Issue Type: Bug Affects Versions: 2.0.0-M2 Reporter: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.0 The "production" content for the Master domain is somewhat broken. When creating a new group, you see the configuration parameters if you don't select an auxiliary class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-811) Error message "'spinner' is required"
[ https://issues.apache.org/jira/browse/SYNCOPE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210603#comment-15210603 ] Colm O hEigeartaigh commented on SYNCOPE-811: - As SYNCOPE-814 appears to be the root cause here, this issue might be resolved by fixing SYNCOPE-814, as normally one shouldn't see the configuration parameters when editing a group... > Error message "'spinner' is required" > - > > Key: SYNCOPE-811 > URL: https://issues.apache.org/jira/browse/SYNCOPE-811 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-spinner.png > > > If you don't specify a value when configuring a Group for a required (int) > parameter, you get a generic error message "'spinner' is required". Instead, > the error message should display the name of the parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-793) "AccountId" + "Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206388#comment-15206388 ] Colm O hEigeartaigh commented on SYNCOPE-793: - Ok thanks Francesco. However, the password flag is not appearing in the UI as per the screenshot I attached. Shall I update the JIRA to reflect this? Colm. > "AccountId" + "Password" keys missing when creating a resource mapping > -- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" instead > of "AccountId" and "Password". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-793) Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-793: Summary: Password" keys missing when creating a resource mapping (was: "AccountId" + "Password" keys missing when creating a resource mapping) > Password" keys missing when creating a resource mapping > --- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" instead > of "AccountId" and "Password". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SYNCOPE-793) Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-793: Description: When creating a new resource mapping, the UI displays "ConnObjectKey" over the first checkbox. However, there is no "title" associated with the "Password" checkbox. (was: When creating a new resource mapping, the UI displays "ConnObjectKey" instead of "AccountId" and "Password".) > Password" keys missing when creating a resource mapping > --- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" over > the first checkbox. However, there is no "title" associated with the > "Password" checkbox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
