[jira] [Resolved] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1243. -- Resolution: Fixed > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2, > SYNCOPE-1243.patch.3, SYNCOPE-1243.patch.4, SYNCOPE-1243.patch.5 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1243: - Attachment: SYNCOPE-1243.patch.5 Take V > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2, > SYNCOPE-1243.patch.3, SYNCOPE-1243.patch.4, SYNCOPE-1243.patch.5 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1243: - Attachment: SYNCOPE-1243.patch.4 Attempt IV, fixing a problem with the last patch + only setting the counts if "details" is true. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2, > SYNCOPE-1243.patch.3, SYNCOPE-1243.patch.4 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282173#comment-16282173 ] Colm O hEigeartaigh commented on SYNCOPE-1243: -- The alternative is just to return an int for the two Any Object count methods. That means everything can be implemented with a simple "count" and we could include the results by default...although of course we'd be losing the information about the individual count for each AnyType. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2, > SYNCOPE-1243.patch.3, SYNCOPE-1243.patch.4 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1243: - Attachment: SYNCOPE-1243.patch.3 Attempt III using "count" in three of the four methods. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2, > SYNCOPE-1243.patch.3 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282046#comment-16282046 ] Colm O hEigeartaigh commented on SYNCOPE-1243: -- Hi Francesco, I'm struggling with the implementation for "countAMembers". The problem is that the JPAAMembership only contains the Any Object Ids and the group Ids, but not the type of the Any Object Ids. So I can easily get a "Count" of all Any Object Ids that are static members of a given group, but not a Map of Any Object types -> count. Colm. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281788#comment-16281788 ] Colm O hEigeartaigh commented on SYNCOPE-1243: -- Hi Francesco, With respect to your first comment - the answer is no, because that is for the static user count: groupTO.setStaticUserMembershipCount(groupDAO.findUMemberships(group).size()); However, given your second comment, I think perhaps it would be better to instead add two methods to count static users and any objects in GroupDAO as well? So: Map countAMembers(Group group); int countUMembers(Group group); WDYT? > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1243: - Attachment: SYNCOPE-1243.patch.2 Take II addressing Francesco's review. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch, SYNCOPE-1243.patch.2 > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280353#comment-16280353 ] Colm O hEigeartaigh commented on SYNCOPE-1243: -- Thanks for the review Francesco. Some comments: a) int countUDynMembers(Group group); Is this really necessary? The implementation is just "return findUDynMembers(group).size();". b) int countADynMembers(Group group); I'll have to change this to "public int countADynMembers(final Group group, final String key)" or else "public Map countADynMembers(final Group group)" - WDYT? > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
[ https://issues.apache.org/jira/browse/SYNCOPE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1243: - Attachment: SYNCOPE-1243.patch A proposed patch for this issue. > Add information to GroupTO about user and AnyObject membership counts > - > > Key: SYNCOPE-1243 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1243.patch > > > If we want to find out how many users or AnyObjects are members of a given > group, it's not possible to figure out via the group itself. Instead we need > to run a fiql on the users or Any Objects. > This task is to add the following fields to GroupTO so that we can get this > information more easily: > - int staticUserMembershipCount > - int dynamicUserMembershipCount > - Map staticAnyObjectMembershipCount > - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1243) Add information to GroupTO about user and AnyObject membership counts
Colm O hEigeartaigh created SYNCOPE-1243: Summary: Add information to GroupTO about user and AnyObject membership counts Key: SYNCOPE-1243 URL: https://issues.apache.org/jira/browse/SYNCOPE-1243 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.7, 2.1.0 If we want to find out how many users or AnyObjects are members of a given group, it's not possible to figure out via the group itself. Instead we need to run a fiql on the users or Any Objects. This task is to add the following fields to GroupTO so that we can get this information more easily: - int staticUserMembershipCount - int dynamicUserMembershipCount - Map staticAnyObjectMembershipCount - Map dynamicAnyObjectMembershipCount -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206249#comment-16206249 ] Colm O hEigeartaigh commented on SYNCOPE-1138: -- LGTM [~ilgrosso], thanks! > Update RelationshipTO to also report the "left" end of a relationship > - > > Key: SYNCOPE-1138 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 > Project: Syncope > Issue Type: Improvement > Components: common, console, core >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.7, 2.1.0 > > Attachments: SYNCOPE-1138.diff > > > Currently, the RelationshipTO object only reports the "right" end of a > relationship. However, as relationships in Syncope are bi-directional, we > should also report the "left" end of a relationship. This will make searching > for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1186. -- Resolution: Fixed > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò >Assignee: Colm O hEigeartaigh > Fix For: 2.0.6 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. Same goes for > SSOValidatorResponse (see [this > commit|https://github.com/apache/syncope/commit/c8748ba107bdda6ae4e8a3aec6dcf4cf9e25a3f6]) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1199) Syncope performance: AnyObjectTO's creation time grows with it's quantity
[
https://issues.apache.org/jira/browse/SYNCOPE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153487#comment-16153487
]
Colm O hEigeartaigh commented on SYNCOPE-1199:
--
Thanks Francesco, the fix looks great and should see a big performance
improvement.
> Syncope performance: AnyObjectTO's creation time grows with it's quantity
> -
>
> Key: SYNCOPE-1199
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1199
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.4
> Environment: Syncope 2.0.2 and 2.0.4 + PostgreSQL 9; Jmeter;
> https://github.com/Talend/platform-services/tree/master/iam/idp
>Reporter: Iurii Smyrnov
>Assignee: Matteo Alessandroni
> Fix For: 2.0.5, 2.1.0
>
> Attachments: CreateTestSyncope_genericResults_AnyObject.csv,
> CreateTestSyncope_graph_AnyObject.csv, CreateTestSyncope.jmx,
> CreateTestSyncope_onlyCreationAggregateReport_AnyObject.csv, Latency for 1000
> create roles (directly syncope 2.0.4) no SCIM.csv, Latency for 1000 create
> roles (directly syncope 2.0.4).png, Latency for 1037 create roles (directly
> syncope 2.0.2) no SCIM.csv, Latency for 1037 create roles (directly syncope
> 2.0.2).png, Latency for 3000 create roles (directly syncope 2.0.2).csv,
> Latency for 3000 create roles (directly syncope 2.0.2).png, Latency for 3000
> create roles (directly syncope 2.0.4).png, MasterContent.xml
>
>
> *AnyObjetcTO's creation time (latency) grows with it's quantity.*
> Testing results are attached (Latency in milliseconds).
> Note: We've tested PostgreSQL DB directly (without Syncope) and we've got
> stable AnyObjetcTO's creation time (not increasing).
> User Syncope 2.0.4 or 2.0.4 and + PostgreSQL 9
> URI: http://localhost:9080/syncope/rest/anyObjects
> http headers:
> 1.Content-Type / application/json
> 2 Accept / application/json
> verb: POST
> body:
> {
> "plainAttrs":[
> {
>"values":[
> "test-value"
>],
>"schema":"roleEntitlements"
> }
> ],
> "type":"RoleAT",
> "realm":"/",
> "@class":"org.apache.syncope.common.lib.to.AnyObjectTO",
> "auxClasses":["RoleATClass"],
> "name":"Role_Account_1"
> }
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (SYNCOPE-1199) Syncope performance: AnyObjectTO's creation time grows with it's quantity
[
https://issues.apache.org/jira/browse/SYNCOPE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reopened SYNCOPE-1199:
--
> Syncope performance: AnyObjectTO's creation time grows with it's quantity
> -
>
> Key: SYNCOPE-1199
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1199
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.4
> Environment: Syncope 2.0.2 and 2.0.4 + PostgreSQL 9; Jmeter;
> https://github.com/Talend/platform-services/tree/master/iam/idp
>Reporter: Iurii Smyrnov
>Assignee: Matteo Alessandroni
> Fix For: 2.0.5
>
> Attachments: CreateTestSyncope_genericResults_AnyObject.csv,
> CreateTestSyncope_graph_AnyObject.csv, CreateTestSyncope.jmx,
> CreateTestSyncope_onlyCreationAggregateReport_AnyObject.csv, Latency for 1000
> create roles (directly syncope 2.0.4) no SCIM.csv, Latency for 1000 create
> roles (directly syncope 2.0.4).png, Latency for 1037 create roles (directly
> syncope 2.0.2) no SCIM.csv, Latency for 1037 create roles (directly syncope
> 2.0.2).png, Latency for 3000 create roles (directly syncope 2.0.2).csv,
> Latency for 3000 create roles (directly syncope 2.0.2).png, Latency for 3000
> create roles (directly syncope 2.0.4).png, MasterContent.xml
>
>
> *AnyObjetcTO's creation time (latency) grows with it's quantity.*
> Testing results are attached (Latency in milliseconds).
> Note: We've tested PostgreSQL DB directly (without Syncope) and we've got
> stable AnyObjetcTO's creation time (not increasing).
> User Syncope 2.0.4 or 2.0.4 and + PostgreSQL 9
> URI: http://localhost:9080/syncope/rest/anyObjects
> http headers:
> 1.Content-Type / application/json
> 2 Accept / application/json
> verb: POST
> body:
> {
> "plainAttrs":[
> {
>"values":[
> "test-value"
>],
>"schema":"roleEntitlements"
> }
> ],
> "type":"RoleAT",
> "realm":"/",
> "@class":"org.apache.syncope.common.lib.to.AnyObjectTO",
> "auxClasses":["RoleATClass"],
> "name":"Role_Account_1"
> }
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1199) Syncope performance: AnyObjectTO's creation time grows with it's quantity
[
https://issues.apache.org/jira/browse/SYNCOPE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved SYNCOPE-1199.
--
Resolution: Fixed
Fix Version/s: 2.0.5
> Syncope performance: AnyObjectTO's creation time grows with it's quantity
> -
>
> Key: SYNCOPE-1199
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1199
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.4
> Environment: Syncope 2.0.2 and 2.0.4 + PostgreSQL 9; Jmeter;
> https://github.com/Talend/platform-services/tree/master/iam/idp
>Reporter: Iurii Smyrnov
>Assignee: Matteo Alessandroni
> Fix For: 2.0.5
>
> Attachments: CreateTestSyncope_genericResults_AnyObject.csv,
> CreateTestSyncope_graph_AnyObject.csv, CreateTestSyncope.jmx,
> CreateTestSyncope_onlyCreationAggregateReport_AnyObject.csv, Latency for 1000
> create roles (directly syncope 2.0.4) no SCIM.csv, Latency for 1000 create
> roles (directly syncope 2.0.4).png, Latency for 1037 create roles (directly
> syncope 2.0.2) no SCIM.csv, Latency for 1037 create roles (directly syncope
> 2.0.2).png, Latency for 3000 create roles (directly syncope 2.0.2).csv,
> Latency for 3000 create roles (directly syncope 2.0.2).png, Latency for 3000
> create roles (directly syncope 2.0.4).png, MasterContent.xml
>
>
> *AnyObjetcTO's creation time (latency) grows with it's quantity.*
> Testing results are attached (Latency in milliseconds).
> Note: We've tested PostgreSQL DB directly (without Syncope) and we've got
> stable AnyObjetcTO's creation time (not increasing).
> User Syncope 2.0.4 or 2.0.4 and + PostgreSQL 9
> URI: http://localhost:9080/syncope/rest/anyObjects
> http headers:
> 1.Content-Type / application/json
> 2 Accept / application/json
> verb: POST
> body:
> {
> "plainAttrs":[
> {
>"values":[
> "test-value"
>],
>"schema":"roleEntitlements"
> }
> ],
> "type":"RoleAT",
> "realm":"/",
> "@class":"org.apache.syncope.common.lib.to.AnyObjectTO",
> "auxClasses":["RoleATClass"],
> "name":"Role_Account_1"
> }
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1199) Syncope performance: AnyObjectTO's creation time grows with it's quantity
[
https://issues.apache.org/jira/browse/SYNCOPE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152741#comment-16152741
]
Colm O hEigeartaigh commented on SYNCOPE-1199:
--
I'll answer my own question here. This issue was fixed as part of:
https://github.com/apache/syncope/commit/120d1e2829abcccf622d9ba5f7028107cb6c8807
The previous code was getting all assignable any objects, even if no
relationships were being defined for the newly created object. With a large
number of AnyObjects I guess this exacts a performance penalty.
The question that springs to mind is whether there is not some way we can avoid
this step even if a relationship is defined? After we find the "other end" via:
AnyObject otherEnd = anyObjectDAO.find(relationshipTO.getRightKey());
is there not some way we can check that we can assign the newly created object
to "otherEnd" without searching through all the assignable objects?
I will mark this issue as "resolved" for 2.0.5, as this fix takes care of the
issue (when no relationships are specified).
> Syncope performance: AnyObjectTO's creation time grows with it's quantity
> -
>
> Key: SYNCOPE-1199
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1199
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.4
> Environment: Syncope 2.0.2 and 2.0.4 + PostgreSQL 9; Jmeter;
> https://github.com/Talend/platform-services/tree/master/iam/idp
>Reporter: Iurii Smyrnov
>Assignee: Matteo Alessandroni
> Attachments: CreateTestSyncope_genericResults_AnyObject.csv,
> CreateTestSyncope_graph_AnyObject.csv, CreateTestSyncope.jmx,
> CreateTestSyncope_onlyCreationAggregateReport_AnyObject.csv, Latency for 1000
> create roles (directly syncope 2.0.4) no SCIM.csv, Latency for 1000 create
> roles (directly syncope 2.0.4).png, Latency for 1037 create roles (directly
> syncope 2.0.2) no SCIM.csv, Latency for 1037 create roles (directly syncope
> 2.0.2).png, Latency for 3000 create roles (directly syncope 2.0.2).csv,
> Latency for 3000 create roles (directly syncope 2.0.2).png, Latency for 3000
> create roles (directly syncope 2.0.4).png, MasterContent.xml
>
>
> *AnyObjetcTO's creation time (latency) grows with it's quantity.*
> Testing results are attached (Latency in milliseconds).
> Note: We've tested PostgreSQL DB directly (without Syncope) and we've got
> stable AnyObjetcTO's creation time (not increasing).
> User Syncope 2.0.4 or 2.0.4 and + PostgreSQL 9
> URI: http://localhost:9080/syncope/rest/anyObjects
> http headers:
> 1.Content-Type / application/json
> 2 Accept / application/json
> verb: POST
> body:
> {
> "plainAttrs":[
> {
>"values":[
> "test-value"
>],
>"schema":"roleEntitlements"
> }
> ],
> "type":"RoleAT",
> "realm":"/",
> "@class":"org.apache.syncope.common.lib.to.AnyObjectTO",
> "auxClasses":["RoleATClass"],
> "name":"Role_Account_1"
> }
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1195) Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1195. -- Resolution: Fixed > Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out > > > Key: SYNCOPE-1195 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1195 > Project: Syncope > Issue Type: Task >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5 > > > Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out. It had to be imported > into Syncope due to WSS-613: https://issues.apache.org/jira/browse/WSS-613 > See [this > commit|https://github.com/apache/syncope/commit/6b3ace024498e4d86bff1e12c782e6c55c036511] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1202) Support IdP Initiated SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1202. -- Resolution: Fixed > Support IdP Initiated SAML SSO > -- > > Key: SYNCOPE-1202 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1202 > Project: Syncope > Issue Type: Improvement > Components: extensions >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1202.patch > > > This task is to support IdP Initiated SAML SSO. This is when a user will > click on a login link in a third-party IdP and be redirected to Syncope, > without having to go to the Syncope console first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1202) Support IdP Initiated SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149035#comment-16149035 ] Colm O hEigeartaigh commented on SYNCOPE-1202: -- You're right, not sure how I missed that :-) > Support IdP Initiated SAML SSO > -- > > Key: SYNCOPE-1202 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1202 > Project: Syncope > Issue Type: Improvement > Components: extensions >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1202.patch > > > This task is to support IdP Initiated SAML SSO. This is when a user will > click on a login link in a third-party IdP and be redirected to Syncope, > without having to go to the Syncope console first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1202) Support IdP Initiated SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149017#comment-16149017 ] Colm O hEigeartaigh commented on SYNCOPE-1202: -- We don't have UI support for the other configuration parameters for the IdP though, unless I'm missing something? You can only upload the metadata, but not configure anything else. > Support IdP Initiated SAML SSO > -- > > Key: SYNCOPE-1202 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1202 > Project: Syncope > Issue Type: Improvement > Components: extensions >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1202.patch > > > This task is to support IdP Initiated SAML SSO. This is when a user will > click on a login link in a third-party IdP and be redirected to Syncope, > without having to go to the Syncope console first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1202) Support IdP Initiated SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1202: - Attachment: SYNCOPE-1202.patch See attached for a patch for this issue. The IdP now has a "supportUnsolicited" boolean property which defaults to false. If it is set to "true", then IdP initiated SAML SSO is supported if the IdP uses a special "idpInitiated" value in the RelayState. I guess we could always support a custom request parameter at a future date as well if required. Tested with OKTA. > Support IdP Initiated SAML SSO > -- > > Key: SYNCOPE-1202 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1202 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1202.patch > > > This task is to support IdP Initiated SAML SSO. This is when a user will > click on a login link in a third-party IdP and be redirected to Syncope, > without having to go to the Syncope console first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1202) Support IdP Initiated SAML SSO
Colm O hEigeartaigh created SYNCOPE-1202: Summary: Support IdP Initiated SAML SSO Key: SYNCOPE-1202 URL: https://issues.apache.org/jira/browse/SYNCOPE-1202 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.5, 2.1.0 This task is to support IdP Initiated SAML SSO. This is when a user will click on a login link in a third-party IdP and be redirected to Syncope, without having to go to the Syncope console first. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1198. -- Resolution: Fixed > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1198: - Attachment: SYNCOPE-1198.patch > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1198: - Attachment: (was: SYNCOPE-1198.patch) > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147074#comment-16147074 ] Colm O hEigeartaigh commented on SYNCOPE-1198: -- Yes probably - I was a bit unsure where to put it. I'll fix this and merge the resulting patch, thanks! > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1199) Syncope performance: AnyObjectTO's creation time grows with it's quantity
[
https://issues.apache.org/jira/browse/SYNCOPE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146974#comment-16146974
]
Colm O hEigeartaigh commented on SYNCOPE-1199:
--
Is it possible to pinpoint what the change in 2.0.5 could be that is yielding
the performance improvement?
Colm.
> Syncope performance: AnyObjectTO's creation time grows with it's quantity
> -
>
> Key: SYNCOPE-1199
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1199
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.4
> Environment: Syncope 2.0.2 and 2.0.4 + PostgreSQL 9; Jmeter;
> https://github.com/Talend/platform-services/tree/master/iam/idp
>Reporter: Iurii Smyrnov
>Assignee: Matteo Alessandroni
> Attachments: CreateTestSyncope_genericResults_AnyObject.csv,
> CreateTestSyncope_graph_AnyObject.csv, CreateTestSyncope.jmx,
> CreateTestSyncope_onlyCreationAggregateReport_AnyObject.csv, Latency for 1000
> create roles (directly syncope 2.0.4) no SCIM.csv, Latency for 1000 create
> roles (directly syncope 2.0.4).png, Latency for 1037 create roles (directly
> syncope 2.0.2) no SCIM.csv, Latency for 1037 create roles (directly syncope
> 2.0.2).png, Latency for 3000 create roles (directly syncope 2.0.2).csv,
> Latency for 3000 create roles (directly syncope 2.0.2).png, Latency for 3000
> create roles (directly syncope 2.0.4).png, MasterContent.xml
>
>
> *AnyObjetcTO's creation time (latency) grows with it's quantity.*
> Testing results are attached (Latency in milliseconds).
> Note: We've tested PostgreSQL DB directly (without Syncope) and we've got
> stable AnyObjetcTO's creation time (not increasing).
> User Syncope 2.0.4 or 2.0.4 and + PostgreSQL 9
> URI: http://localhost:9080/syncope/rest/anyObjects
> http headers:
> 1.Content-Type / application/json
> 2 Accept / application/json
> verb: POST
> body:
> {
> "plainAttrs":[
> {
>"values":[
> "test-value"
>],
>"schema":"roleEntitlements"
> }
> ],
> "type":"RoleAT",
> "realm":"/",
> "@class":"org.apache.syncope.common.lib.to.AnyObjectTO",
> "auxClasses":["RoleATClass"],
> "name":"Role_Account_1"
> }
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1198: - Attachment: SYNCOPE-1198.patch A revised patch using enums instead. > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1198: - Attachment: (was: SYNCOPE-1198.patch) > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
[ https://issues.apache.org/jira/browse/SYNCOPE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1198: - Attachment: SYNCOPE-1198.patch Proposed patch...please review! > Make the signature algorithm configurable for SAML SSO > -- > > Key: SYNCOPE-1198 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: SYNCOPE-1198.patch > > > This task is to make the signature algorithm configurable for SAML SSO. > Currently it is hard-coded depending on the key in question. I propose to add > a new configuration property "signature.algorithm" to the > saml2sp-logic.properties file. If undefined then it defaults to the previous > behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1198) Make the signature algorithm configurable for SAML SSO
Colm O hEigeartaigh created SYNCOPE-1198: Summary: Make the signature algorithm configurable for SAML SSO Key: SYNCOPE-1198 URL: https://issues.apache.org/jira/browse/SYNCOPE-1198 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.5, 2.1.0 This task is to make the signature algorithm configurable for SAML SSO. Currently it is hard-coded depending on the key in question. I propose to add a new configuration property "signature.algorithm" to the saml2sp-logic.properties file. If undefined then it defaults to the previous behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1197) Enduser console doesn't specify "SAML 2.0" as per the admin console
[ https://issues.apache.org/jira/browse/SYNCOPE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125834#comment-16125834 ] Colm O hEigeartaigh commented on SYNCOPE-1197: -- For consistency, would it also be possible to put it below the "Login" button as per the admin console? > Enduser console doesn't specify "SAML 2.0" as per the admin console > --- > > Key: SYNCOPE-1197 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1197 > Project: Syncope > Issue Type: Improvement > Components: standalone >Reporter: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > Attachments: admin-console.png, enduser-console.png > > > The enduser console doesn't include any text referring to "SAML 2.0" as the > admin console does (see attached screenshots). It should be updated to look > like the admin console. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1197) Enduser console doesn't specify "SAML 2.0" as per the admin console
[ https://issues.apache.org/jira/browse/SYNCOPE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125793#comment-16125793 ] Colm O hEigeartaigh commented on SYNCOPE-1197: -- No, via the standalone distribution on master. > Enduser console doesn't specify "SAML 2.0" as per the admin console > --- > > Key: SYNCOPE-1197 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1197 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > Attachments: admin-console.png, enduser-console.png > > > The enduser console doesn't include any text referring to "SAML 2.0" as the > admin console does (see attached screenshots). It should be updated to look > like the admin console. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1197) Enduser console doesn't specify "SAML 2.0" as per the admin console
[ https://issues.apache.org/jira/browse/SYNCOPE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1197: - Attachment: admin-console.png enduser-console.png > Enduser console doesn't specify "SAML 2.0" as per the admin console > --- > > Key: SYNCOPE-1197 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1197 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > Attachments: admin-console.png, enduser-console.png > > > The enduser console doesn't include any text referring to "SAML 2.0" as the > admin console does (see attached screenshots). It should be updated to look > like the admin console. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1197) Enduser console doesn't specify "SAML 2.0" as per the admin console
Colm O hEigeartaigh created SYNCOPE-1197: Summary: Enduser console doesn't specify "SAML 2.0" as per the admin console Key: SYNCOPE-1197 URL: https://issues.apache.org/jira/browse/SYNCOPE-1197 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Priority: Trivial Fix For: 2.0.5, 2.1.0 The enduser console doesn't include any text referring to "SAML 2.0" as the admin console does (see attached screenshots). It should be updated to look like the admin console. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1195) Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1195: - Description: Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out. It had to be imported into Syncope due to WSS-613: https://issues.apache.org/jira/browse/WSS-613 See [this commit|https://github.com/apache/syncope/commit/6b3ace024498e4d86bff1e12c782e6c55c036511] was:Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out. It had to be imported into Syncope due to WSS-613: https://issues.apache.org/jira/browse/WSS-613 > Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out > > > Key: SYNCOPE-1195 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1195 > Project: Syncope > Issue Type: Task >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5 > > > Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out. It had to be imported > into Syncope due to WSS-613: https://issues.apache.org/jira/browse/WSS-613 > See [this > commit|https://github.com/apache/syncope/commit/6b3ace024498e4d86bff1e12c782e6c55c036511] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1194) Sign the SAML SSO Service Provider Metadata
[ https://issues.apache.org/jira/browse/SYNCOPE-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1194. -- Resolution: Fixed > Sign the SAML SSO Service Provider Metadata > --- > > Key: SYNCOPE-1194 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1194 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > Currently the Service Provider Metadata for SAML SSO is not signed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1186: - Description: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. Same goes for SSOValidatorResponse (see [this commit|https://github.com/apache/syncope/commit/c8748ba107bdda6ae4e8a3aec6dcf4cf9e25a3f6]) was: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. Same goes for SSOValidatorResponse (see a8b278a09a17700faaf8822674c90b123f0f4ff2) > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. Same goes for > SSOValidatorResponse (see [this > commit|https://github.com/apache/syncope/commit/c8748ba107bdda6ae4e8a3aec6dcf4cf9e25a3f6]) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-1186: Assignee: Colm O hEigeartaigh > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. Same goes for > SSOValidatorResponse (see a8b278a09a17700faaf8822674c90b123f0f4ff2) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1195) Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out
Colm O hEigeartaigh created SYNCOPE-1195: Summary: Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out Key: SYNCOPE-1195 URL: https://issues.apache.org/jira/browse/SYNCOPE-1195 Project: Syncope Issue Type: Task Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.5 Remove copy of OpenSAMLUtil when WSS4J 2.1.11 is out. It had to be imported into Syncope due to WSS-613: https://issues.apache.org/jira/browse/WSS-613 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1186: - Description: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. Same goes for SSOValidatorResponse (see a8b278a09a17700faaf8822674c90b123f0f4ff2) was: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. Same goes for SSOValidatorResponse. > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò > Fix For: 2.0.5 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. Same goes for > SSOValidatorResponse (see a8b278a09a17700faaf8822674c90b123f0f4ff2) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1186: - Summary: Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out (was: Remove copy of SAMLSSOResponseValidator when CXF 3.1.13 is out) > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò > Fix For: 2.0.5 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1186) Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF 3.1.13 is out
[ https://issues.apache.org/jira/browse/SYNCOPE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1186: - Description: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. Same goes for SSOValidatorResponse. was: For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after [this commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. Once CXF 3.1.13 is out, such local copy must be removed. > Remove copy of SAMLSSOResponseValidator and SSOValidatorResponse when CXF > 3.1.13 is out > --- > > Key: SYNCOPE-1186 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1186 > Project: Syncope > Issue Type: Task > Components: extensions >Reporter: Francesco Chicchiriccò > Fix For: 2.0.5 > > > For SYNCOPE-1185 there was the need to import SAMLSSOResponseValidator after > [this > commit|https://github.com/apache/cxf/commit/726e6190d54643d4bcd84f876f9d051a7376f398]. > Once CXF 3.1.13 is out, such local copy must be removed. Same goes for > SSOValidatorResponse. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1194) Sign the SAML SSO Service Provider Metadata
Colm O hEigeartaigh created SYNCOPE-1194: Summary: Sign the SAML SSO Service Provider Metadata Key: SYNCOPE-1194 URL: https://issues.apache.org/jira/browse/SYNCOPE-1194 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.5, 2.1.0 Currently the Service Provider Metadata for SAML SSO is not signed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1171) Skip Relationships page when no relationships exist
[ https://issues.apache.org/jira/browse/SYNCOPE-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111339#comment-16111339 ] Colm O hEigeartaigh commented on SYNCOPE-1171: -- What I meant here was to skip the page if no relationship types are defined in syncope. The "+" button is meaningless in this context, as you can't create a relationship anyway if there are no types available. Not a big deal either way though :-) > Skip Relationships page when no relationships exist > --- > > Key: SYNCOPE-1171 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1171 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Colm O hEigeartaigh >Priority: Trivial > Attachments: relationships.png > > > When creating a new user in the console, with no relationships defined, you > come to a page that says: > Relationships > No relationships defined > It would be better just to skip this page altogether if no relationships are > available. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1179) JWT "Date" claims are interpreted using milliseconds instead of seconds
[ https://issues.apache.org/jira/browse/SYNCOPE-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1179. -- Resolution: Fixed > JWT "Date" claims are interpreted using milliseconds instead of seconds > --- > > Key: SYNCOPE-1179 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1179 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > We currently treat (create + validate) JWT tokens with the claims "exp", > "iat" and "nbf" as millisecond values. However the spec says that they should > be seconds instead: > https://tools.ietf.org/html/rfc7519 > NumericDate > A JSON numeric value representing the number of seconds from > 1970-01-01T00:00:00Z UTC until the specified UTC date/time, > ignoring leap seconds. > exp: ... Its value MUST be a number >containing a NumericDate value. > nbf: ... Its value MUST be a number containing a >NumericDate value. > iat: ... Its >value MUST be a number containing a NumericDate value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1179) JWT "Date" claims are interpreted using milliseconds instead of seconds
Colm O hEigeartaigh created SYNCOPE-1179: Summary: JWT "Date" claims are interpreted using milliseconds instead of seconds Key: SYNCOPE-1179 URL: https://issues.apache.org/jira/browse/SYNCOPE-1179 Project: Syncope Issue Type: Bug Affects Versions: 2.0.4 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.5, 2.1.0 We currently treat (create + validate) JWT tokens with the claims "exp", "iat" and "nbf" as millisecond values. However the spec says that they should be seconds instead: https://tools.ietf.org/html/rfc7519 NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. exp: ... Its value MUST be a number containing a NumericDate value. nbf: ... Its value MUST be a number containing a NumericDate value. iat: ... Its value MUST be a number containing a NumericDate value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1174) NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present
[ https://issues.apache.org/jira/browse/SYNCOPE-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104805#comment-16104805 ] Colm O hEigeartaigh commented on SYNCOPE-1174: -- +1 for the patch > NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is > present > --- > > Key: SYNCOPE-1174 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1174 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > Attachments: > 0001-SYNCOPE-1174-More-robust-conf-params-default-value-m.patch > > > There is a NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' > schema is present in the relevant Content.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1174) NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present
[ https://issues.apache.org/jira/browse/SYNCOPE-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103387#comment-16103387 ] Colm O hEigeartaigh commented on SYNCOPE-1174: -- It was just an issue I ran into while upgrading from 2.0.2 to 2.0.4. NPE checks for all of the schemas is probably overkill. I'm happy to revert it if you object? > NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is > present > --- > > Key: SYNCOPE-1174 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1174 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > > There is a NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' > schema is present in the relevant Content.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1174) NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present
[ https://issues.apache.org/jira/browse/SYNCOPE-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1174. -- Resolution: Fixed > NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is > present > --- > > Key: SYNCOPE-1174 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1174 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.5, 2.1.0 > > > There is a NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' > schema is present in the relevant Content.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1174) NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present
Colm O hEigeartaigh created SYNCOPE-1174: Summary: NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present Key: SYNCOPE-1174 URL: https://issues.apache.org/jira/browse/SYNCOPE-1174 Project: Syncope Issue Type: Bug Affects Versions: 2.0.4 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Trivial Fix For: 2.0.5, 2.1.0 There is a NPE in AccessTokenDataBinderImpl if no 'jwt.lifetime.minutes' schema is present in the relevant Content.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1173. -- Resolution: Fixed > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103036#comment-16103036 ] Colm O hEigeartaigh commented on SYNCOPE-1173: -- I also added some into GroupITCase, e.g.: assertTrue(memberships.stream().anyMatch(m -> m.getGroupKey().equals(groupKey))); I'm not aware of any maven plugin that highlights where Java 8 APIs could be used... > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101830#comment-16101830 ] Colm O hEigeartaigh commented on SYNCOPE-1173: -- Francesco, could you review my merge to master when you get a chance? Once you're happy I'll backmerge it. BTW does Syncope have a position on introducing JAva 8 idioms to master? I used the streams API a bit in the tests. It's a lot cleaner but I guess I have to rewrite it for 2.0.x... Colm. > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101825#comment-16101825 ] Colm O hEigeartaigh commented on SYNCOPE-1173: -- OK fair enough. > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1173: - Fix Version/s: 2.0.5 > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101801#comment-16101801 ] Colm O hEigeartaigh commented on SYNCOPE-1173: -- Well it'll break the API because I'm removing List dynGroups? > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1173: - Description: This task is to replace List dynGroups with List dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the dynamic group names associated with a given user or Any Object when doing a GET, as opposed to the current situation where we only see the keys of the group. (was: This task is to replace List dynGroups with List dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the dynamic group names associated with a given user or Any Object when doing a GET for the user, as opposed to the current situation where we only see the keys of the group.) > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET, as opposed to the current situation where we only see the keys of the > group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
Colm O hEigeartaigh created SYNCOPE-1173: Summary: Replace List dynGroups with List dynMemberships Key: SYNCOPE-1173 URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.1.0 This task is to replace dynGroups with List dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the dynamic group names associated with a given user or Any Object when doing a GET for the user, as opposed to the current situation where we only see the keys of the group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1173) Replace List dynGroups with List dynMemberships
[ https://issues.apache.org/jira/browse/SYNCOPE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1173: - Description: This task is to replace List dynGroups with List dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the dynamic group names associated with a given user or Any Object when doing a GET for the user, as opposed to the current situation where we only see the keys of the group. (was: This task is to replace dynGroups with List dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the dynamic group names associated with a given user or Any Object when doing a GET for the user, as opposed to the current situation where we only see the keys of the group.) > Replace List dynGroups with List dynMemberships > - > > Key: SYNCOPE-1173 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1173 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.1.0 > > > This task is to replace List dynGroups with List > dynMemberships in UserTO and AnyObjectTO. This will allow us to retrieve the > dynamic group names associated with a given user or Any Object when doing a > GET for the user, as opposed to the current situation where we only see the > keys of the group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1172) Error message of "Malformed Path" could be made a little clearer
[ https://issues.apache.org/jira/browse/SYNCOPE-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1172. -- Resolution: Fixed > Error message of "Malformed Path" could be made a little clearer > > > Key: SYNCOPE-1172 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1172 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.5, 2.1.0 > > > When creating a user, group etc. via the REST API and not specifying a realm, > you get an error back: > "MalformedPathException: Malformed path: null" > This is not very informative, as it's not immediately obvious it relates to > the realm. I propose to replace the error message with "The provided realm > path is malformed". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1172) Error message of "Malformed Path" could be made a little clearer
Colm O hEigeartaigh created SYNCOPE-1172: Summary: Error message of "Malformed Path" could be made a little clearer Key: SYNCOPE-1172 URL: https://issues.apache.org/jira/browse/SYNCOPE-1172 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 2.0.5, 2.1.0 When creating a user, group etc. via the REST API and not specifying a realm, you get an error back: "MalformedPathException: Malformed path: null" This is not very informative, as it's not immediately obvious it relates to the realm. I propose to replace the error message with "The provided realm path is malformed". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1171) Skip Relationships page when no relationships exist
Colm O hEigeartaigh created SYNCOPE-1171: Summary: Skip Relationships page when no relationships exist Key: SYNCOPE-1171 URL: https://issues.apache.org/jira/browse/SYNCOPE-1171 Project: Syncope Issue Type: Improvement Components: console Reporter: Colm O hEigeartaigh Priority: Trivial Fix For: 2.1.0 When creating a new user in the console, with no relationships defined, you come to a page that says: Relationships No relationships defined It would be better just to skip this page altogether if no relationships are available. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1170) Can't remove a "Dynamic USER assignment"
Colm O hEigeartaigh created SYNCOPE-1170: Summary: Can't remove a "Dynamic USER assignment" Key: SYNCOPE-1170 URL: https://issues.apache.org/jira/browse/SYNCOPE-1170 Project: Syncope Issue Type: Bug Components: console Reporter: Colm O hEigeartaigh Fix For: 2.0.5, 2.1.0 Steps to reproduce: a) Create a user "alice". b) Create a group "employee" with a dynamic user assignment (username == alice). c) Verify that alice is a dynamic member of the group "employee". d) Now edit "employee" and "-" the search condition for dynamic user assignment and click finish. e) The condition is not deleted as expected, alice is still a member of the group. Edit the group again and the dynamic user condition search is still in place. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1165) Switch the default password cipher algorithm from SHA1 to SSHA256
[ https://issues.apache.org/jira/browse/SYNCOPE-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1165. -- Resolution: Fixed > Switch the default password cipher algorithm from SHA1 to SSHA256 > - > > Key: SYNCOPE-1165 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1165 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.1.0 > > > For 2.1.0, we should switch the default password cipher algorithm from SHA-1 > to SSHA256. We might as well be more secure "by default" as some users won't > change the default values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SYNCOPE-1165) Switch the default password cipher algorithm from SHA1 to SSHA256
[ https://issues.apache.org/jira/browse/SYNCOPE-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-1165: Assignee: Colm O hEigeartaigh > Switch the default password cipher algorithm from SHA1 to SSHA256 > - > > Key: SYNCOPE-1165 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1165 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.1.0 > > > For 2.1.0, we should switch the default password cipher algorithm from SHA-1 > to SSHA256. We might as well be more secure "by default" as some users won't > change the default values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1165) Switch the default password cipher algorithm from SHA1 to SSHA256
[ https://issues.apache.org/jira/browse/SYNCOPE-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1165: - Summary: Switch the default password cipher algorithm from SHA1 to SSHA256 (was: Switch the default password cipher algorithm from SHA1 to S-SHA-256) > Switch the default password cipher algorithm from SHA1 to SSHA256 > - > > Key: SYNCOPE-1165 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1165 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh > Fix For: 2.1.0 > > > For 2.1.0, we should switch the default password cipher algorithm from SHA-1 > to SSHA256. We might as well be more secure "by default" as some users won't > change the default values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1165) Switch the default password cipher algorithm from SHA1 to S-SHA-256
[ https://issues.apache.org/jira/browse/SYNCOPE-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1165: - Summary: Switch the default password cipher algorithm from SHA1 to S-SHA-256 (was: Switch the default password cipher algorithm from SHA1 to SSHA256) > Switch the default password cipher algorithm from SHA1 to S-SHA-256 > --- > > Key: SYNCOPE-1165 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1165 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh > Fix For: 2.1.0 > > > For 2.1.0, we should switch the default password cipher algorithm from SHA-1 > to SSHA256. We might as well be more secure "by default" as some users won't > change the default values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1168) Encryptor pads short secret keys with "0" instead of random characters
[ https://issues.apache.org/jira/browse/SYNCOPE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1168. -- Resolution: Fixed > Encryptor pads short secret keys with "0" instead of random characters > -- > > Key: SYNCOPE-1168 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1168 > Project: Syncope > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.2.11, 2.0.5, 2.1.0 > > > Encryptor pads short secret keys with "0" instead of random characters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1168) Encryptor pads short secret keys with "0" instead of random characters
Colm O hEigeartaigh created SYNCOPE-1168: Summary: Encryptor pads short secret keys with "0" instead of random characters Key: SYNCOPE-1168 URL: https://issues.apache.org/jira/browse/SYNCOPE-1168 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.2.11, 2.0.5, 2.1.0 Encryptor pads short secret keys with "0" instead of random characters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1165) Switch the default password cipher algorithm from SHA1 to SSHA256
Colm O hEigeartaigh created SYNCOPE-1165: Summary: Switch the default password cipher algorithm from SHA1 to SSHA256 Key: SYNCOPE-1165 URL: https://issues.apache.org/jira/browse/SYNCOPE-1165 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.1.0 For 2.1.0, we should switch the default password cipher algorithm from SHA-1 to SSHA256. We might as well be more secure "by default" as some users won't change the default values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074512#comment-16074512 ] Colm O hEigeartaigh commented on SYNCOPE-1138: -- > That's my idea to improve the current implementation, yes. > To keep things simple, I would replace the rightKey field with otherKey. OK makes sense. Is there an issue with changing the API for 2.0.5? > That's usually the trickiest part, I don't have any ready-to-cook recipe, I > should take a closer look. Maybe an idea to have a feature branch for this > issue where we can commit our partial work? +1 from me. > Update RelationshipTO to also report the "left" end of a relationship > - > > Key: SYNCOPE-1138 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 > Project: Syncope > Issue Type: Improvement > Components: common, console, core >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > Currently, the RelationshipTO object only reports the "right" end of a > relationship. However, as relationships in Syncope are bi-directional, we > should also report the "left" end of a relationship. This will make searching > for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1149) Access token still required for the third party JWT SSO integration scenario
Colm O hEigeartaigh created SYNCOPE-1149:
Summary: Access token still required for the third party JWT SSO
integration scenario
Key: SYNCOPE-1149
URL: https://issues.apache.org/jira/browse/SYNCOPE-1149
Project: Syncope
Issue Type: Bug
Affects Versions: 2.0.4
Reporter: Colm O hEigeartaigh
Fix For: 2.0.5, 2.1.0
When trying to invoke on Syncope with a third-party JWT, the code in
AuthDataAccessor.authenticate still errors if no access token is found:
AccessToken accessToken =
accessTokenDAO.find(authentication.getClaims().getTokenId());
if (accessToken == null) {
throw new AuthenticationCredentialsNotFoundException(
"Could not find JWT " +
authentication.getClaims().getTokenId());
}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073928#comment-16073928 ] Colm O hEigeartaigh commented on SYNCOPE-1138: -- Thanks Francesco. I have two further questions at this point: a) Is left/right dependent on which object the relationship was initially defined on? In the example above, does the PRINTER return a "right-key" for the relationship, and the DEVICE a "left-key"? b) How can I set the relationship on the other object? I tried in AnyObjectDataBinderImpl.create doing something like "otherEnd.add(relationship);" after the ARelationship is set on "anyObject", but I get an error along the lines of: org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged object "org.apache.syncope.core.persistence.jpa.entity.anyobject.JPAAnyObject@48eccd7c" in life cycle state unmanaged while cascading persistence via field "org.apache.syncope.core.persistence.jpa.entity.anyobject.JPAARelationship.leftEnd" during flush. However, this field does not allow cascade persist. You cannot flush unmanaged objects or graphs that have persistent associations to unmanaged objects. > Update RelationshipTO to also report the "left" end of a relationship > - > > Key: SYNCOPE-1138 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 > Project: Syncope > Issue Type: Improvement > Components: common, console, core >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > Currently, the RelationshipTO object only reports the "right" end of a > relationship. However, as relationships in Syncope are bi-directional, we > should also report the "left" end of a relationship. This will make searching > for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072708#comment-16072708 ] Colm O hEigeartaigh commented on SYNCOPE-1138: -- A few thoughts on this: a) Should we report both ends of the relationship or only the "opposite" end of the Relationship via RelationshipTO? It seems a bit redundant for example to state the left hand side of a relationship if it is the same AnyType that is being returned. b) Should we do the same for MembershipTO? c) What is the best way to set the "opposite" side of the Relationship? For example, when returning an AnyType object, should we search for the "left" relationships associated with this object. Or when setting a relationship in the opposite direction on creation/update, do we then set it on the other side of the relationship? > Update RelationshipTO to also report the "left" end of a relationship > - > > Key: SYNCOPE-1138 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 > Project: Syncope > Issue Type: Improvement > Components: common, console, core >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > Currently, the RelationshipTO object only reports the "right" end of a > relationship. However, as relationships in Syncope are bi-directional, we > should also report the "left" end of a relationship. This will make searching > for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-1138: Assignee: Colm O hEigeartaigh > Update RelationshipTO to also report the "left" end of a relationship > - > > Key: SYNCOPE-1138 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 > Project: Syncope > Issue Type: Improvement > Components: common, console, core >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > > Currently, the RelationshipTO object only reports the "right" end of a > relationship. However, as relationships in Syncope are bi-directional, we > should also report the "left" end of a relationship. This will make searching > for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1140) Error when trying to assign a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1140: - Priority: Minor (was: Major) > Error when trying to assign a relationship > -- > > Key: SYNCOPE-1140 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1140 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.0.5, 2.1.0 > > Attachments: syncope-error.png > > > If I try to assign a relationship in the Console, where I don't select a > "Type" but select a rightType and then click on "select" I see the following > error (see attached screenshot). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1140) Error when trying to assign a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1140: - Description: If I try to assign a relationship in the Console, where I don't select a "Type" but select a rightType and then click on "select" I see the following error (see attached screenshot). (was: When trying to assign a relationship in the Console, I see the following error (see attached screenshot). It definately works with 2.0.3, so the error has crept in since then.) > Error when trying to assign a relationship > -- > > Key: SYNCOPE-1140 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1140 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh > Fix For: 2.0.5, 2.1.0 > > Attachments: syncope-error.png > > > If I try to assign a relationship in the Console, where I don't select a > "Type" but select a rightType and then click on "select" I see the following > error (see attached screenshot). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1140) Error when trying to assign a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1140: - Description: When trying to assign a relationship in the Console, I see the following error (see attached screenshot). It definately works with 2.0.3, so the error has crept in since then. (was: When trying to assign a relationship in the Console, I see the following error (see attached screenshot). This must have crept in lately, as it was working up to recently.) > Error when trying to assign a relationship > -- > > Key: SYNCOPE-1140 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1140 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh > Attachments: syncope-error.png > > > When trying to assign a relationship in the Console, I see the following > error (see attached screenshot). It definately works with 2.0.3, so the error > has crept in since then. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1140) Error when trying to assign a relationship
[ https://issues.apache.org/jira/browse/SYNCOPE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1140: - Attachment: syncope-error.png > Error when trying to assign a relationship > -- > > Key: SYNCOPE-1140 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1140 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.4 >Reporter: Colm O hEigeartaigh > Attachments: syncope-error.png > > > When trying to assign a relationship in the Console, I see the following > error (see attached screenshot). This must have crept in lately, as it was > working up to recently. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1140) Error when trying to assign a relationship
Colm O hEigeartaigh created SYNCOPE-1140: Summary: Error when trying to assign a relationship Key: SYNCOPE-1140 URL: https://issues.apache.org/jira/browse/SYNCOPE-1140 Project: Syncope Issue Type: Bug Components: console Affects Versions: 2.0.4 Reporter: Colm O hEigeartaigh When trying to assign a relationship in the Console, I see the following error (see attached screenshot). This must have crept in lately, as it was working up to recently. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1138) Update RelationshipTO to also report the "left" end of a relationship
Colm O hEigeartaigh created SYNCOPE-1138: Summary: Update RelationshipTO to also report the "left" end of a relationship Key: SYNCOPE-1138 URL: https://issues.apache.org/jira/browse/SYNCOPE-1138 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.0.5 Currently, the RelationshipTO object only reports the "right" end of a relationship. However, as relationships in Syncope are bi-directional, we should also report the "left" end of a relationship. This will make searching for AnyTypes a bit easier than it is at present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships
[ https://issues.apache.org/jira/browse/SYNCOPE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1132. -- Resolution: Not A Problem Thanks Fabio, I guess it was a cache issue, I can't reproduce it when I try again. > Extraneous "dots" appearing in the Console when assigning relationships > --- > > Key: SYNCOPE-1132 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1132 > Project: Syncope > Issue Type: Bug > Components: console >Reporter: Colm O hEigeartaigh >Assignee: fabio martelli >Priority: Trivial > Fix For: 2.0.4, 2.1.0 > > Attachments: occurredprop.png, syncope-dots.png > > > There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I > confirmed it is not present in 2.0.3) where extra "dots" are appearing in the > screen. I can reproduce by assigning a relationship to an AnyObject for > example in the console. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships
Colm O hEigeartaigh created SYNCOPE-1132: Summary: Extraneous "dots" appearing in the Console when assigning relationships Key: SYNCOPE-1132 URL: https://issues.apache.org/jira/browse/SYNCOPE-1132 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Priority: Trivial Fix For: 2.0.4, 2.1.0 Attachments: syncope-dots.png There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I confirmed it is not present in 2.0.3) where extra "dots" are appearing in the screen. I can reproduce by assigning a relationship to an AnyObject for example in the console. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships
[ https://issues.apache.org/jira/browse/SYNCOPE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1132: - Attachment: syncope-dots.png Two black dots are present that should not be there. > Extraneous "dots" appearing in the Console when assigning relationships > --- > > Key: SYNCOPE-1132 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1132 > Project: Syncope > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Priority: Trivial > Fix For: 2.0.4, 2.1.0 > > Attachments: syncope-dots.png > > > There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I > confirmed it is not present in 2.0.3) where extra "dots" are appearing in the > screen. I can reproduce by assigning a relationship to an AnyObject for > example in the console. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1129) Third Party JWT SSO integration
Colm O hEigeartaigh created SYNCOPE-1129:
Summary: Third Party JWT SSO integration
Key: SYNCOPE-1129
URL: https://issues.apache.org/jira/browse/SYNCOPE-1129
Project: Syncope
Issue Type: New Feature
Reporter: Colm O hEigeartaigh
Assignee: Francesco Chicchiriccò
Fix For: 2.0.4
This task is to support SSO using third party JWT tokens.
It involves two tasks:
a) Create a new interface extending JwsSignatureVerifier to provide a method to
resolve a JWT subject into Syncope username (known user).
b) When processing a received token, if the issuer is different from the known
issuer ("jwtIssuer" in security.properties), then instead of retrieving the
default jwsSignatureVerifier implementation, the authentication component will
enable the ClassPathScanImplementationLookup to dynamically discover an
implementation of the interface above.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1119) Make it more obvious that the default admin password needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1119. -- Resolution: Fixed > Make it more obvious that the default admin password needs to be changed > > > Key: SYNCOPE-1119 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1119 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > As per SYNCOPE-1117, this task is to make it more obvious that the > "adminPassword" property needs to be changed. This involves: > a) Update the installer to ask for an "adminPassword" value. > b) Print a warning in the logs if we detect that the default key is being > used. > The docs changes are already done as part of SYNCOPE-1117. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1119) Make it more obvious that the default admin password needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1119: - Description: As per SYNCOPE-1117, this task is to make it more obvious that the "adminPassword" property needs to be changed. This involves: a) Update the installer to ask for an "adminPassword" value. b) Print a warning in the logs if we detect that the default key is being used. The docs changes are already done as part of SYNCOPE-1117. was: As per SYNCOPE-1117, this task is to make it more obvious that the "adminPassword" property needs to be changed. This involves: a) Update the maven archetype and the installer to ask for an "adminPassword" value. b) Print a warning in the logs if we detect that the default key is being used. The docs changes are already done as part of SYNCOPE-1117. > Make it more obvious that the default admin password needs to be changed > > > Key: SYNCOPE-1119 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1119 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > As per SYNCOPE-1117, this task is to make it more obvious that the > "adminPassword" property needs to be changed. This involves: > a) Update the installer to ask for an "adminPassword" value. > b) Print a warning in the logs if we detect that the default key is being > used. > The docs changes are already done as part of SYNCOPE-1117. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1119) Make it more obvious that the default admin password needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062795#comment-16062795 ] Colm O hEigeartaigh commented on SYNCOPE-1119: -- Yeah agreed. I can still support it in the installer by hashing the value and then writing this out as a property. > Make it more obvious that the default admin password needs to be changed > > > Key: SYNCOPE-1119 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1119 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > As per SYNCOPE-1117, this task is to make it more obvious that the > "adminPassword" property needs to be changed. This involves: > a) Update the maven archetype and the installer to ask for an "adminPassword" > value. > b) Print a warning in the logs if we detect that the default key is being > used. > The docs changes are already done as part of SYNCOPE-1117. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1120) Use the standard Bearer Authorization header for JWT tokens
[ https://issues.apache.org/jira/browse/SYNCOPE-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1120. -- Resolution: Fixed > Use the standard Bearer Authorization header for JWT tokens > --- > > Key: SYNCOPE-1120 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1120 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > As discussed on the mailing list, this task is to switch to use the standard > Bearer Authorization header instead of X-Syncope-Token when invoking on REST > services: > https://t.co/QwLRejSgJL -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SYNCOPE-1119) Make it more obvious that the default admin password needs to be changed
[
https://issues.apache.org/jira/browse/SYNCOPE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060825#comment-16060825
]
Colm O hEigeartaigh commented on SYNCOPE-1119:
--
One problem with specifying the admin password in the archetype is that there
is no easy way to hash the value before saving it as ${adminPassword}...anyone
any ideas on this?
> Make it more obvious that the default admin password needs to be changed
>
>
> Key: SYNCOPE-1119
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1119
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.4, 2.1.0
>
>
> As per SYNCOPE-1117, this task is to make it more obvious that the
> "adminPassword" property needs to be changed. This involves:
> a) Update the maven archetype and the installer to ask for an "adminPassword"
> value.
> b) Print a warning in the logs if we detect that the default key is being
> used.
> The docs changes are already done as part of SYNCOPE-1117.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1117) Make it more obvious that the jwsKey needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1117. -- Resolution: Fixed > Make it more obvious that the jwsKey needs to be changed > > > Key: SYNCOPE-1117 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1117 > Project: Syncope > Issue Type: Improvement > Components: archetype, core, documentation >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > This task is to make it more obvious that the "jwsKey" property needs to be > changed. This involves: > a) Update the maven archetype and the installer to ask for a "jwsKey" value. > b) Update the docs for the installer, standalone and deb versions to make it > clear that the "jwsKey" value needs to be changed. > c) Print a warning in the logs if we detect that the default key is being > used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1120) Use the standard Bearer Authorization header for JWT tokens
Colm O hEigeartaigh created SYNCOPE-1120: Summary: Use the standard Bearer Authorization header for JWT tokens Key: SYNCOPE-1120 URL: https://issues.apache.org/jira/browse/SYNCOPE-1120 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.4, 2.1.0 As discussed on the mailing list, this task is to switch to use the standard Bearer Authorization header instead of X-Syncope-Token when invoking on REST services: https://t.co/QwLRejSgJL -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1119) Make it more obvious that the default admin password needs to be changed
Colm O hEigeartaigh created SYNCOPE-1119: Summary: Make it more obvious that the default admin password needs to be changed Key: SYNCOPE-1119 URL: https://issues.apache.org/jira/browse/SYNCOPE-1119 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.0.4, 2.1.0 As per SYNCOPE-1117, this task is to make it more obvious that the "adminPassword" property needs to be changed. This involves: a) Update the maven archetype and the installer to ask for an "adminPassword" value. b) Print a warning in the logs if we detect that the default key is being used. The docs changes are already done as part of SYNCOPE-1117. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SYNCOPE-1117) Make it more obvious that the jwsKey needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated SYNCOPE-1117: - Description: This task is to make it more obvious that the "jwsKey" property needs to be changed. This involves: a) Update the maven archetype and the installer to ask for a "jwsKey" value. b) Update the docs for the installer, standalone and deb versions to make it clear that the "jwsKey" value needs to be changed. c) Print a warning in the logs if we detect that the default key is being used. was: This task is to make it more obvious that the "jwsKey" property needs to be changed. This involves: a) Update the maven archetype to ask for a "jwsKey" value. b) Update the docs for the installer, standalone and deb versions to make it clear that the "jwsKey" value needs to be changed. c) Print a warning in the logs if we detect that the default key is being used. > Make it more obvious that the jwsKey needs to be changed > > > Key: SYNCOPE-1117 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1117 > Project: Syncope > Issue Type: Improvement > Components: archetype, core, documentation >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > This task is to make it more obvious that the "jwsKey" property needs to be > changed. This involves: > a) Update the maven archetype and the installer to ask for a "jwsKey" value. > b) Update the docs for the installer, standalone and deb versions to make it > clear that the "jwsKey" value needs to be changed. > c) Print a warning in the logs if we detect that the default key is being > used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SYNCOPE-1117) Make it more obvious that the jwsKey needs to be changed
[ https://issues.apache.org/jira/browse/SYNCOPE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-1117: Assignee: Colm O hEigeartaigh > Make it more obvious that the jwsKey needs to be changed > > > Key: SYNCOPE-1117 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1117 > Project: Syncope > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4 > > > This task is to make it more obvious that the "jwsKey" property needs to be > changed. This involves: > a) Update the maven archetype to ask for a "jwsKey" value. > b) Update the docs for the installer, standalone and deb versions to make it > clear that the "jwsKey" value needs to be changed. > c) Print a warning in the logs if we detect that the default key is being > used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1118) Update docs to explain what "anonymousKey" refers to
Colm O hEigeartaigh created SYNCOPE-1118: Summary: Update docs to explain what "anonymousKey" refers to Key: SYNCOPE-1118 URL: https://issues.apache.org/jira/browse/SYNCOPE-1118 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.0.4 In the getting-started guide, "anonymousKey" is defined as: "Provide any pseudo-random string here that will be used as an authentication key for anonymous requests". However, anonymous requests are not referenced again in the getting started guide or in the reference guide. We should add something (I guess to the latter) to explain what anonymous requests are. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SYNCOPE-1117) Make it more obvious that the jwsKey needs to be changed
Colm O hEigeartaigh created SYNCOPE-1117: Summary: Make it more obvious that the jwsKey needs to be changed Key: SYNCOPE-1117 URL: https://issues.apache.org/jira/browse/SYNCOPE-1117 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.0.4 This task is to make it more obvious that the "jwsKey" property needs to be changed. This involves: a) Update the maven archetype to ask for a "jwsKey" value. b) Update the docs for the installer, standalone and deb versions to make it clear that the "jwsKey" value needs to be changed. c) Print a warning in the logs if we detect that the default key is being used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SYNCOPE-1107) The installer fails with a NoClassDefFoundError
[ https://issues.apache.org/jira/browse/SYNCOPE-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved SYNCOPE-1107. -- Resolution: Fixed > The installer fails with a NoClassDefFoundError > --- > > Key: SYNCOPE-1107 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1107 > Project: Syncope > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.0.4, 2.1.0 > > > If you try to install Syncope via the installer you see an error: > Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: > org/apache/commons/lang3/StringUtils > at > org.apache.syncope.installer.validators.ArchetypeValidator.validateData(ArchetypeValidator.java:31) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
