[jira] [Resolved] (SYNCOPE-1765) allow WA to decrypt properties during the configuration bootstrap phase
[
https://issues.apache.org/jira/browse/SYNCOPE-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed resolved SYNCOPE-1765.
-
Resolution: Fixed
> allow WA to decrypt properties during the configuration bootstrap phase
> ---
>
> Key: SYNCOPE-1765
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1765
> Project: Syncope
> Issue Type: Improvement
> Components: core, wa
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3
> Reporter: Misagh Moayyed
> Assignee: Misagh Moayyed
>Priority: Major
> Fix For: 3.0.4, 4.0.0
>
>
> Configuration properties that are read during the bootstrapping phase should
> be optionally decoded, as they may have been stored in an encrypted format
> that follows "\{cas-cipher}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1765) allow WA to decrypt properties during the configuration bootstrap phase
[
https://issues.apache.org/jira/browse/SYNCOPE-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed updated SYNCOPE-1765:
Description: Configuration properties that are read during the
bootstrapping phase should be optionally decoded, as they may have been stored
in an encrypted format that follows "\{cas-cipher}" (was: Allow each
AuthModuleConf component to selectively encrypt/decrypt values/settings before
the final conf is stored in the syncope database.)
> allow WA to decrypt properties during the configuration bootstrap phase
> ---
>
> Key: SYNCOPE-1765
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1765
> Project: Syncope
> Issue Type: Improvement
> Components: core, wa
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Misagh Moayyed
>Assignee: Misagh Moayyed
>Priority: Major
> Fix For: 3.0.4, 4.0.0
>
>
> Configuration properties that are read during the bootstrapping phase should
> be optionally decoded, as they may have been stored in an encrypted format
> that follows "\{cas-cipher}"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1765) allow WA to decrypt properties during the configuration bootstrap phase
[ https://issues.apache.org/jira/browse/SYNCOPE-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1765: Summary: allow WA to decrypt properties during the configuration bootstrap phase (was: Encrypt/Decrypt auth module configurations selectively) > allow WA to decrypt properties during the configuration bootstrap phase > --- > > Key: SYNCOPE-1765 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1765 > Project: Syncope > Issue Type: Improvement > Components: core, wa >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.0.3 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.4, 4.0.0 > > > Allow each AuthModuleConf component to selectively encrypt/decrypt > values/settings before the final conf is stored in the syncope database. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SYNCOPE-1765) Encrypt/Decrypt auth module configurations selectively
Misagh Moayyed created SYNCOPE-1765: --- Summary: Encrypt/Decrypt auth module configurations selectively Key: SYNCOPE-1765 URL: https://issues.apache.org/jira/browse/SYNCOPE-1765 Project: Syncope Issue Type: Improvement Components: core, wa Affects Versions: 3.0.3, 3.0.2, 3.0.1, 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.4, 4.0.0 Allow each AuthModuleConf component to selectively encrypt/decrypt values/settings before the final conf is stored in the syncope database. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1722) Allow password fields to reveal their value to the end-user
[ https://issues.apache.org/jira/browse/SYNCOPE-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1722: Fix Version/s: 2.1.14 3.0.2 > Allow password fields to reveal their value to the end-user > --- > > Key: SYNCOPE-1722 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1722 > Project: Syncope > Issue Type: Improvement > Components: console, enduser >Affects Versions: 2.1.13, 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.14, 3.0.2 > > > Provide an option so the password field can switch its type from password to > text and back, allowing the user to see the value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1722) Allow password fields to reveal their value to the end-user
[ https://issues.apache.org/jira/browse/SYNCOPE-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1722: Affects Version/s: 3.0.0 2.1.13 > Allow password fields to reveal their value to the end-user > --- > > Key: SYNCOPE-1722 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1722 > Project: Syncope > Issue Type: Improvement > Components: console, enduser >Affects Versions: 2.1.13, 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > > Provide an option so the password field can switch its type from password to > text and back, allowing the user to see the value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1722) Allow password fields to reveal their value to the end-user
[ https://issues.apache.org/jira/browse/SYNCOPE-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1722: Component/s: console > Allow password fields to reveal their value to the end-user > --- > > Key: SYNCOPE-1722 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1722 > Project: Syncope > Issue Type: Improvement > Components: console, enduser > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > > Provide an option so the password field can switch its type from password to > text and back, allowing the user to see the value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SYNCOPE-1722) Allow password fields to reveal their value to the end-user
Misagh Moayyed created SYNCOPE-1722: --- Summary: Allow password fields to reveal their value to the end-user Key: SYNCOPE-1722 URL: https://issues.apache.org/jira/browse/SYNCOPE-1722 Project: Syncope Issue Type: Improvement Components: enduser Reporter: Misagh Moayyed Assignee: Misagh Moayyed Provide an option so the password field can switch its type from password to text and back, allowing the user to see the value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SYNCOPE-1709) Persist Jobs' current status in the database to support multi-node deployments
[ https://issues.apache.org/jira/browse/SYNCOPE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1709. - Resolution: Fixed > Persist Jobs' current status in the database to support multi-node > deployments > --- > > Key: SYNCOPE-1709 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1709 > Project: Syncope > Issue Type: Improvement >Affects Versions: 2.1.12, 3.0.0-M2 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.13, 3.0.1 > > > When jobs, particularly (long-running) reports, are scheduled/asked to run > and there are multiple Syncope core nodes available in the cluster, the > current method of obtaining the job status via Spring and Quartz fails to > report back the status accurately, specially when the job bean is scheduled > on one node and the status check query is performed on another. > To support this scenario, job status details would be persisted in the > backend database in a new table, and the job engine would be responsible to > add/update/delete details in this table. Status query checks would then look > into this table to report back current status instead of obtaining the status > from the Spring bean responsible for execution. > it was discussed that the initial changeset would go into master and be > targeted to Syncope v3, and then may be backported to 2.x pending feasibility > and complication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SYNCOPE-1709) Persist Jobs' current status in the database to support multi-node deployments
Misagh Moayyed created SYNCOPE-1709: --- Summary: Persist Jobs' current status in the database to support multi-node deployments Key: SYNCOPE-1709 URL: https://issues.apache.org/jira/browse/SYNCOPE-1709 Project: Syncope Issue Type: Improvement Affects Versions: 3.0.0-M2, 2.1.12 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0, 2.1.12 When jobs, particularly (long-running) reports, are scheduled/asked to run and there are multiple Syncope core nodes available in the cluster, the current method of obtaining the job status via Spring and Quartz fails to report back the status accurately, specially when the job bean is scheduled on one node and the status check query is performed on another. To support this scenario, job status details would be persisted in the backend database in a new table, and the job engine would be responsible to add/update/delete details in this table. Status query checks would then look into this table to report back current status instead of obtaining the status from the Spring bean responsible for execution. it was discussed that the initial changeset would go into master and be targeted to Syncope v3, and then may be backported to 2.x pending feasibility and complication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Apache Syncope 3.0.0-M1
+1. On Fri, Oct 14, 2022 at 12:29 PM Fabio Martelli wrote: > > +1 > Regards > > On Fri, Oct 14, 2022 at 9:16 AM Francesco Chicchiriccò > wrote: > > > > I've created a 3.0-0-M1 release, with the following artifacts up for a vote: > > > > GIT source tag (680fc58faf): > > https://gitbox.apache.org/repos/asf?p=syncope.git;a=tag;h=680fc58faf > > > > List of changes: > > https://gitbox.apache.org/repos/asf?p=syncope.git;a=blob_plain;f=CHANGES;hb=680fc58faf > > > > Staging artifacts: > > https://dist.apache.org/repos/dist/dev/syncope/3.0.0-M1/ > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachesyncope-1072/ > > > > Staging site: > > https://syncope.apache.org/3.0.0-M1/index.html > > > > PGP release keys (signed using 273DF287): > > http://www.apache.org/dist/syncope/KEYS > > > > Vote will be open for 72 hours. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > Here's my +1 > > Regards. > > > > -- > > Francesco Chicchiriccò > > > > Tirasa - Open Source Excellence > > http://www.tirasa.net/ > > > > Member at The Apache Software Foundation > > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > > http://home.apache.org/~ilgrosso/ > >
[jira] [Resolved] (SYNCOPE-1699) Extract key from path for UserUpdate ops if undefined in request body
[ https://issues.apache.org/jira/browse/SYNCOPE-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1699. - Resolution: Fixed > Extract key from path for UserUpdate ops if undefined in request body > - > > Key: SYNCOPE-1699 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1699 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 3.0.0-M0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Minor > Fix For: 3.0.0-M1, 3.0.0 > > > If a user-update operations via a PATCH (i.e. PATCH /users/key) does not > specify a key in the request body, this key should be extracted from the > path. The extracted key in the body must always equal the key in the path. In > the event that a key does not match or cannot be found, a 400 BAD REQUEST > error should be returned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SYNCOPE-1699) Extract key from path for UserUpdate ops if undefined in request body
[ https://issues.apache.org/jira/browse/SYNCOPE-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1699: Summary: Extract key from path for UserUpdate ops if undefined in request body (was: Extract key from path for UserUpdate Ops if undefined in request body) > Extract key from path for UserUpdate ops if undefined in request body > - > > Key: SYNCOPE-1699 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1699 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 3.0.0-M0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Minor > Fix For: 3.0.0-M1, 3.0.0 > > > If a user-update operations via a PATCH (i.e. PATCH /users/key) does not > specify a key in the request body, this key should be extracted from the > path. The extracted key in the body must always equal the key in the path. In > the event that a key does not match or cannot be found, a 400 BAD REQUEST > error should be returned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SYNCOPE-1699) Extract key from path for UserUpdate Ops if undefined in request body
Misagh Moayyed created SYNCOPE-1699: --- Summary: Extract key from path for UserUpdate Ops if undefined in request body Key: SYNCOPE-1699 URL: https://issues.apache.org/jira/browse/SYNCOPE-1699 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 3.0.0-M0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0-M1, 3.0.0 If a user-update operations via a PATCH (i.e. PATCH /users/key) does not specify a key in the request body, this key should be extracted from the path. The extracted key in the body must always equal the key in the path. In the event that a key does not match or cannot be found, a 400 BAD REQUEST error should be returned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Remove Camel Provisioning Manager
In general, I am in favor of this approach, but just to be on the safe side, would it make sense to deprecate the feature first? Just in case someone out there is using it, or would keeping the code around cause complications and maintenance issues? On Wed, Aug 24, 2022 at 4:16 AM Francesco Chicchiriccò wrote: > > Hi all, > working for SYNCOPE-1692, which involves some changes in the provisioning > process, I've realized that the Camel Provisioning Manager extension [1], > while featuring some very smart code has probably never been used in any > production deployment, at least none that I am aware of. > > Over time, the cost of managing such (possibly unused) extension has become > quite relevant, hence I am proposing to remove it from the master branch, so > that next 3.0.0 release will not contain it anymore. > > Thoughts? > Regards. > > [1] https://github.com/apache/syncope/tree/master/ext/camel > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ >
[jira] [Resolved] (SYNCOPE-1681) Support LDAP Google Auth Tokens/Accounts in WA
[ https://issues.apache.org/jira/browse/SYNCOPE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1681. - Resolution: Fixed > Support LDAP Google Auth Tokens/Accounts in WA > -- > > Key: SYNCOPE-1681 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1681 > Project: Syncope > Issue Type: New Feature > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Registration records, tokens, etc that are relevant for google authenticator > as an mfa provider should be optionally stored in an LDAP backend for Syncope > WA. > The LDAP support for GAuth already exists: > [https://apereo.github.io/cas/6.5.x/mfa/GoogleAuthenticator-Authentication-Registration-LDAP.html] > > The task here is to augment the google auth configuration to support > appropriate LDAP settings, and then conditionally activate the module when > settings specified. If settings are undefined, we defer to Syncope as the > backend service (which is the default today) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SYNCOPE-1681) Support LDAP Google Auth Tokens/Accounts in WA
Misagh Moayyed created SYNCOPE-1681: --- Summary: Support LDAP Google Auth Tokens/Accounts in WA Key: SYNCOPE-1681 URL: https://issues.apache.org/jira/browse/SYNCOPE-1681 Project: Syncope Issue Type: New Feature Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Registration records, tokens, etc that are relevant for google authenticator as an mfa provider should be optionally stored in an LDAP backend for Syncope WA. The LDAP support for GAuth already exists: [https://apereo.github.io/cas/6.5.x/mfa/GoogleAuthenticator-Authentication-Registration-LDAP.html] The task here is to augment the google auth configuration to support appropriate LDAP settings, and then conditionally activate the module when settings specified. If settings are undefined, we defer to Syncope as the backend service (which is the default today) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (SYNCOPE-1680) Support Simple MFA as an MFA Provider in WA
[ https://issues.apache.org/jira/browse/SYNCOPE-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1680. - Resolution: Fixed > Support Simple MFA as an MFA Provider in WA > --- > > Key: SYNCOPE-1680 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1680 > Project: Syncope > Issue Type: New Feature > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Allow WA to act as a multifactor authentication provider on its own, issuing > tokens and sending them to end-users via pre-defined communication channels > such as email or text messages. Tokens issued by WA are tracked using the > [ticket > registry|https://apereo.github.io/cas/6.5.x/ticketing/Configuring-Ticketing-Components.html] > and are assigned a configurable expiration policy controlled via WA settings. > See: > https://apereo.github.io/cas/6.5.x/mfa/Simple-Multifactor-Authentication.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SYNCOPE-1680) Support Simple MFA as an MFA Provider in WA
Misagh Moayyed created SYNCOPE-1680: --- Summary: Support Simple MFA as an MFA Provider in WA Key: SYNCOPE-1680 URL: https://issues.apache.org/jira/browse/SYNCOPE-1680 Project: Syncope Issue Type: New Feature Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Allow WA to act as a multifactor authentication provider on its own, issuing tokens and sending them to end-users via pre-defined communication channels such as email or text messages. Tokens issued by WA are tracked using the [ticket registry|https://apereo.github.io/cas/6.5.x/ticketing/Configuring-Ticketing-Components.html] and are assigned a configurable expiration policy controlled via WA settings. See: https://apereo.github.io/cas/6.5.x/mfa/Simple-Multifactor-Authentication.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
Re: [VOTE] Apache Syncope 2.1.10
+1 for sure. --Misagh - Original Message - > From: "Marco Di Sabatino Di Diodoro" > To: "dev" , "Francesco Chicchiriccò" > > Sent: Friday, October 8, 2021 5:23:10 PM > Subject: Re: [VOTE] Apache Syncope 2.1.10 > Il 08/10/21 09:47, Francesco Chicchiriccò ha scritto: >> I've created a 2.1.10 release, with the following artifacts up for a >> vote: >> >> GIT source tag (d47a976): >> https://gitbox.apache.org/repos/asf?p=syncope.git;a=tag;h=0761b43 >> >> List of changes: >> https://gitbox.apache.org/repos/asf?p=syncope.git;a=blob;f=CHANGES;hb=0761b43 >> >> >> Staging artifacts: >> https://dist.apache.org/repos/dist/dev/syncope/2.1.10/ >> >> Maven staging repo: >> https://repository.apache.org/content/repositories/orgapachesyncope-1068/ >> >> Staging site: >> http://syncope.apache.org/2.1.10/index.html >> >> PGP release keys (signed using 273DF287): >> http://www.apache.org/dist/syncope/KEYS >> >> Vote will be open for 72 hours. >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) > > +1 > > Regards > M > >> >> Here's my +1 >> Regards. >> > -- > Dott. Marco Di Sabatino Di Diodoro > Tel. +39 3939065570 > > Tirasa S.r.l. > Viale Vittoria Colonna, 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 085973 > http://www.tirasa.net > > Apache Syncope PMC Member > http://people.apache.org/~mdisabatino/
Re: [DISCUSS] Netbeans plugin removal from 3.0.0
+1. --Misagh - Original Message - > From: "Marco Di Sabatino Di Diodoro" > To: "dev" , "Francesco Chicchiriccò" > > Sent: Tuesday, August 10, 2021 5:55:01 PM > Subject: Re: [DISCUSS] Netbeans plugin removal from 3.0.0 > Il 10/08/21 15:41, Francesco Chicchiriccò ha scritto: >> Hi all, >> as already happened for other components like as Eclipse IDE plugin, >> CLI, GUI Installer, deb packages, here I am with proposal to remove >> the Netbeans IDE plugin, starting with upcoming release 3.0.0. >> >> Motivations are quite the same as for other components: no actual >> reported usage. >> In addition, SYNCOPE-1403 [1] (which would make the plugin quite >> useful) has been out for some time with no volunteer. >> >> FTR, in case of revamp, it will not be difficult to up-port the code >> from branch 2_1_X. >> >> Any objection to removal? >> >> Regards. >> >> [1] https://issues.apache.org/jira/browse/SYNCOPE-1403 > > > No objection > M > > -- > Dott. Marco Di Sabatino Di Diodoro > Tel. +39 3939065570 > > Tirasa S.r.l. > Viale Vittoria Colonna, 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 085973 > http://www.tirasa.net > > Apache Syncope PMC Member > http://people.apache.org/~mdisabatino/
[jira] [Commented] (SYNCOPE-1626) rename package org.apache.syncope.common.keymaster.client.zookeper to zookeeper
[
https://issues.apache.org/jira/browse/SYNCOPE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314704#comment-17314704
]
Misagh Moayyed commented on SYNCOPE-1626:
-
Great. Thanks for the clarification!
> rename package org.apache.syncope.common.keymaster.client.zookeper to
> zookeeper
> ---
>
> Key: SYNCOPE-1626
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1626
> Project: Syncope
> Issue Type: Bug
> Components: keymaster
>Reporter: Josh Soref
>Assignee: Francesco Chicchiriccò
>Priority: Trivial
> Fix For: 3.0.0
>
>
> I understand that classes like to last forever, but,
> [https://zookeeper.apache.org/]
> {quote}Welcome to Apache ZooKeeper™
> Apache ZooKeeper is an effort to develop and maintain an open-source server
> which enables highly reliable distributed coordination.
> What is ZooKeeper?
> {quote}
> Wouldn't it be nice if the brand of another ASF project was spelled correctly?
> For reference:
> [https://github.com/search?q=org%3Aapache+ZOOKEPER&type=Code]
> 270 code results
>
> [https://github.com/search?q=org%3Aapache+ZOOKEEPER&type=Code]
> 39,245 code results
> I normally run project wide spelling fixes, but I'm currently trying to get
> Apache Hive fixed up, and that's not making fast progress
> (https://issues.apache.org/jira/browse/HIVE-24390), so I don't expect to
> visit this project anytime soon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SYNCOPE-1626) rename package org.apache.syncope.common.keymaster.client.zookeper to zookeeper
[
https://issues.apache.org/jira/browse/SYNCOPE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed closed SYNCOPE-1626.
---
Resolution: Invalid
If you have a specific example in Apache Syncope that misspells zookeeper,
please be specific.
> rename package org.apache.syncope.common.keymaster.client.zookeper to
> zookeeper
> ---
>
> Key: SYNCOPE-1626
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1626
> Project: Syncope
> Issue Type: Bug
> Components: keymaster
>Reporter: Josh Soref
>Priority: Trivial
>
> I understand that classes like to last forever, but,
> [https://zookeeper.apache.org/]
> {quote}Welcome to Apache ZooKeeper™
> Apache ZooKeeper is an effort to develop and maintain an open-source server
> which enables highly reliable distributed coordination.
> What is ZooKeeper?
> {quote}
> Wouldn't it be nice if the brand of another ASF project was spelled correctly?
> For reference:
> [https://github.com/search?q=org%3Aapache+ZOOKEPER&type=Code]
> 270 code results
>
> [https://github.com/search?q=org%3Aapache+ZOOKEEPER&type=Code]
> 39,245 code results
> I normally run project wide spelling fixes, but I'm currently trying to get
> Apache Hive fixed up, and that's not making fast progress
> (https://issues.apache.org/jira/browse/HIVE-24390), so I don't expect to
> visit this project anytime soon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1625) Support impersonation for Web Access
[ https://issues.apache.org/jira/browse/SYNCOPE-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1625. - Resolution: Fixed > Support impersonation for Web Access > > > Key: SYNCOPE-1625 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1625 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Allow Web Access to support impersonation of accounts for login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1625) Support impersonation for Web Access
Misagh Moayyed created SYNCOPE-1625: --- Summary: Support impersonation for Web Access Key: SYNCOPE-1625 URL: https://issues.apache.org/jira/browse/SYNCOPE-1625 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Allow Web Access to support impersonation of accounts for login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1618) Use Constructor-level dependency injections
[ https://issues.apache.org/jira/browse/SYNCOPE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1618: Description: See [syncope-dev|http://example.com] discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control was: See syncope-dev discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control > Use Constructor-level dependency injections > --- > > Key: SYNCOPE-1618 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 > Project: Syncope > Issue Type: Task > Components: common, console, core, sra, wa >Affects Versions: 2.1.8 > Reporter: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > See [syncope-dev|http://example.com] discussion at > [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] > In summary: > * Avoid field-injections and use ctor-level injections (this is the general > recommendation from Spring) > * Do not use autowire/component/etc directly in business-level classes; do > not rely as much (if ever) on classpath/context scanning and instead, create > and instantiate the bean directory in @Configuration classes, conditionally > and with direct control > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1618) Use Constructor-level dependency injections
[ https://issues.apache.org/jira/browse/SYNCOPE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1618: Description: See [syncope-dev|https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] discussion. In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control was: See [syncope-dev|http://example.com] discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control > Use Constructor-level dependency injections > --- > > Key: SYNCOPE-1618 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 > Project: Syncope > Issue Type: Task > Components: common, console, core, sra, wa >Affects Versions: 2.1.8 > Reporter: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > See > [syncope-dev|https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] > discussion. > In summary: > * Avoid field-injections and use ctor-level injections (this is the general > recommendation from Spring) > * Do not use autowire/component/etc directly in business-level classes; do > not rely as much (if ever) on classpath/context scanning and instead, create > and instantiate the bean directory in @Configuration classes, conditionally > and with direct control > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1618) Use Constructor-level dependency injections
[ https://issues.apache.org/jira/browse/SYNCOPE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1618: Description: See syncope-dev discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control was: See [syncope-dev discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control > Use Constructor-level dependency injections > --- > > Key: SYNCOPE-1618 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 > Project: Syncope > Issue Type: Task > Components: common, console, core, sra, wa >Affects Versions: 2.1.8 > Reporter: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > See syncope-dev discussion at > [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] > In summary: > * Avoid field-injections and use ctor-level injections (this is the general > recommendation from Spring) > * Do not use autowire/component/etc directly in business-level classes; do > not rely as much (if ever) on classpath/context scanning and instead, create > and instantiate the bean directory in @Configuration classes, conditionally > and with direct control > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1618) Use Constructor-level dependency injections
[ https://issues.apache.org/jira/browse/SYNCOPE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1618: Issue Type: Task (was: Improvement) > Use Constructor-level dependency injections > --- > > Key: SYNCOPE-1618 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 > Project: Syncope > Issue Type: Task > Components: common, console, core, sra, wa >Affects Versions: 2.1.8 > Reporter: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > See [syncope-dev discussion at > [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] > In summary: > * Avoid field-injections and use ctor-level injections (this is the general > recommendation from Spring) > * Do not use autowire/component/etc directly in business-level classes; do > not rely as much (if ever) on classpath/context scanning and instead, create > and instantiate the bean directory in @Configuration classes, conditionally > and with direct control > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1618) Use Constructor-level dependency injections
Misagh Moayyed created SYNCOPE-1618: --- Summary: Use Constructor-level dependency injections Key: SYNCOPE-1618 URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 Project: Syncope Issue Type: Improvement Components: common, console, core, sra, wa Affects Versions: 2.1.8 Reporter: Misagh Moayyed Fix For: 3.0.0 See [syncope-dev discussion|[https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E].] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1618) Use Constructor-level dependency injections
[ https://issues.apache.org/jira/browse/SYNCOPE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1618: Description: See [syncope-dev discussion at [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control was: See [syncope-dev discussion|[https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E].] In summary: * Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) * Do not use autowire/component/etc directly in business-level classes; do not rely as much (if ever) on classpath/context scanning and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control > Use Constructor-level dependency injections > --- > > Key: SYNCOPE-1618 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1618 > Project: Syncope > Issue Type: Improvement > Components: common, console, core, sra, wa >Affects Versions: 2.1.8 > Reporter: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > See [syncope-dev discussion at > [https://lists.apache.org/thread.html/r99530cad4c763eb8d97f52575be46ed74f088cd43271600b0b1d7ee2%40%3Cdev.syncope.apache.org%3E] > In summary: > * Avoid field-injections and use ctor-level injections (this is the general > recommendation from Spring) > * Do not use autowire/component/etc directly in business-level classes; do > not rely as much (if ever) on classpath/context scanning and instead, create > and instantiate the bean directory in @Configuration classes, conditionally > and with direct control > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Proposal: using ctor-level dependency injection
Thank you all. Sounds like we have consensus. I'll proceed to create a JIRA to track the task. --Misagh - Original Message - > From: "Andrea Patricelli" > To: "dev" > Sent: Monday, February 22, 2021 7:44:13 PM > Subject: Re: Proposal: using ctor-level dependency injection > Hi Misagh, > > definitely +1 also from me! > > Best regards, > Andrea > > On 19/02/21 11:41, Misagh Moayyed wrote: >> Hello all, >> >> I want to discuss and propose a design change in the way Syncope components, >> specially *Logic classes are constructed. For a concrete example, this >> component [1] might be a good baseline. >> >> Components such as [1] do two things that seem less than ideal: >> >> 1) The class is directly annotated with a @Component >> 2) It uses field-injections by annotating fields with @Autowire and such >> >> I submit that this approach generally proves challenging, specially when it >> comes to constructing a context for integration tests and dealing with >> classpath scanning. There is lot of literature on why this (field injections) >> might not be an ideal approach; The "test context and component scanning" is >> one practical example that I myself ran into; Purists might also argue that >> business-level components and logic classes should not be tied to the upper >> framework per se (though I don't actually find myself in this camp all too >> often!). >> >> A better alternative perhaps would be: >> >> - Avoid field-injections and use ctor-level injections (this is the general >> recommendation from Spring) >> - Do not use autowire/component/etc directly in business-level classes >> - ...which means do not rely as much (if ever) on classpath/context scanning >> - ...and instead, create and instantiate the bean directory in @Configuration >> classes, conditionally and with direct control >> - ...or use a middle-ground for now, with something like this [2] >> >> The work feels largely cosmetic perhaps; I think it will pay off in the >> future >> specially if it's something that is advocated by Spring and family. >> >> WDYT? >> >> --Misagh >> >> [1] >> https://github.com/apache/syncope/blob/master/core/am/logic/src/main/java/org/apache/syncope/core/logic/OIDCJWKSLogic.java >> [2] >> https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/using-boot-spring-beans-and-dependency-injection.html >> > -- > Andrea Patricelli > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope
Proposal: using ctor-level dependency injection
Hello all, I want to discuss and propose a design change in the way Syncope components, specially *Logic classes are constructed. For a concrete example, this component [1] might be a good baseline. Components such as [1] do two things that seem less than ideal: 1) The class is directly annotated with a @Component 2) It uses field-injections by annotating fields with @Autowire and such I submit that this approach generally proves challenging, specially when it comes to constructing a context for integration tests and dealing with classpath scanning. There is lot of literature on why this (field injections) might not be an ideal approach; The "test context and component scanning" is one practical example that I myself ran into; Purists might also argue that business-level components and logic classes should not be tied to the upper framework per se (though I don't actually find myself in this camp all too often!). A better alternative perhaps would be: - Avoid field-injections and use ctor-level injections (this is the general recommendation from Spring) - Do not use autowire/component/etc directly in business-level classes - ...which means do not rely as much (if ever) on classpath/context scanning - ...and instead, create and instantiate the bean directory in @Configuration classes, conditionally and with direct control - ...or use a middle-ground for now, with something like this [2] The work feels largely cosmetic perhaps; I think it will pay off in the future specially if it's something that is advocated by Spring and family. WDYT? --Misagh [1] https://github.com/apache/syncope/blob/master/core/am/logic/src/main/java/org/apache/syncope/core/logic/OIDCJWKSLogic.java [2] https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/using-boot-spring-beans-and-dependency-injection.html
Re: State of Syncope 3.0
Thank you, Francesco. Excellent stuff and it's exciting to see this goodness come to life. I would support the idea of doing an RC; for advanced users or those who might been following the activity on Github or other developers building against Syncope, this could prove useful. Of course, this is assuming the release-engineering effort is reasonable (and speaking of which, we could explore whether this bit may also be automated using Travis CI; we could let the robots do all the work before their eventual uprising and return of Arnold Schwarzenegger!) Happy Friday! --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Monday, February 15, 2021 3:33:05 PM > Subject: State of Syncope 3.0 > Hi all, > I thought I could spend a few words to describe the current status of our > efforts towards Syncope 3.0. > > Starting point is [1] where the overall code reorganization - now completed - > and the new components are introduced. > Also relevant is [2] which describes the identified issues in JIRA for the new > major version. > > Overall, this is the state by component: > > * Core is completed with several enhancements and improvements > > * Console was upgraded to latest components and technologies but is still > lacking the features to manage WA (Keymaster and SRA management was done, > instead) > > * Enduser was rewritten from scratch to uniform with Console as much as > possible > but needs work to finalize and possibly include new features derived from WA > as > auth profile management or SAML2 / OIDC account linking > > * SRA is completed > > * Keymaster is completed and provided in two flavors: self, e.g. REST and > internal storage based, and zookeeper, requiring an Apache Zookeeper > deployment > > * WA, based on Apereo CAS 6.4, is mostly completed but under continuous > refinement > > * Documentation is the sore point, essentially stuck at the same content as > 2.1 > > Similarly as we've done at the time of Syncope 2.0, I believe it is the case > to > publish some RCs before the official 3.0.0. > I don't think, however, we are yet a the point of issuing RC1, as we'd need at > least to: > > 1. update the Documentations at least with main changes > > 2. bring the Enduser application at a degree of usability > > 3. introduce at least some WA configuration items for Console > > WDYT? > Regards. > > [1] > https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Syncope+3.0 > [2] https://issues.apache.org/jira/projects/SYNCOPE/versions/12322510 > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
Re: Rolling new release: 2.1.8
Same here. +1. --Misagh - Original Message - > From: "Andrea Patricelli" > To: "dev" > Sent: Thursday, December 17, 2020 3:19:56 PM > Subject: Re: Rolling new release: 2.1.8 > Hi all, > > no issues on my side, rather I totally agree with the proposal since > 2.1.8 fixes and improvements are quite important. > > Best regards and have a nice and holy Christmas, > Andrea > > Il 17/12/20 12:15, Francesco Chicchiriccò ha scritto: >> Hi all, >> given the fact that we have some important fixes available for 2.1.8 [1], I >> would like to start soon the release process, with purpose of delivering a >> nice >> Christmas present to our users. >> >> Do you see any problem? >> >> Regards. >> >> [1] >> https://issues.apache.org/jira/issues/?jql=statusCategory%20%3D%20done%20AND%20project%20%3D%2012313120%20AND%20fixVersion%20%3D%2012348788%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC >> > -- > Dott. Andrea Patricelli > Tel. +39 3204524292 > > Engineer @ Tirasa S.r.l. > Viale Vittoria Colonna 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 085973 > http://www.tirasa.net > > Apache Syncope PMC Member
[jira] [Resolved] (SYNCOPE-1599) Support Duo Security for MFA
[ https://issues.apache.org/jira/browse/SYNCOPE-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1599. - Resolution: Fixed > Support Duo Security for MFA > > > Key: SYNCOPE-1599 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1599 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > DuoSecurity is a very popular MFA provider specially in higher education and > K12 markets. Integration requires an active duo subscription, which allows > CAS/WA to provide MFA in form of webauthn, one-time codes, push notifications > and phone calls. Device registration and management is handled by Duo itself > and there is a built-in mechanism provided by Duo as part of the MFA flow to > handle account registrations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1599) Support Duo Security for MFA
Misagh Moayyed created SYNCOPE-1599: --- Summary: Support Duo Security for MFA Key: SYNCOPE-1599 URL: https://issues.apache.org/jira/browse/SYNCOPE-1599 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 DuoSecurity is a very popular MFA provider specially in higher education and K12 markets. Integration requires an active duo subscription, which allows CAS/WA to provide MFA in form of webauthn, one-time codes, push notifications and phone calls. Device registration and management is handled by Duo itself and there is a built-in mechanism provided by Duo as part of the MFA flow to handle account registrations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1595) Support themes per client application
[ https://issues.apache.org/jira/browse/SYNCOPE-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1595. - Resolution: Fixed > Support themes per client application > - > > Key: SYNCOPE-1595 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1595 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Allow theme names to be defined for each client app, and possibly put > together a sample theme perhaps for WA to demonstrate functionality. > Furthermore, consider designing REST APIs that can allow CAS to fetch a full > view/page instead of relying on static predefined themes and css/html. A WA > user should be able to modify the contents of a given page/view, store that > page somewhere and let the Syncope REST API fetch that view if the client > application requires it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1595) Support themes per client application
Misagh Moayyed created SYNCOPE-1595: --- Summary: Support themes per client application Key: SYNCOPE-1595 URL: https://issues.apache.org/jira/browse/SYNCOPE-1595 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Allow theme names to be defined for each client app, and possibly put together a sample theme perhaps for WA to demonstrate functionality. Furthermore, consider designing REST APIs that can allow CAS to fetch a full view/page instead of relying on static predefined themes and css/html. A WA user should be able to modify the contents of a given page/view, store that page somewhere and let the Syncope REST API fetch that view if the client application requires it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1593) Allow SAML2 SPs to override signing/encryption algorithms
[ https://issues.apache.org/jira/browse/SYNCOPE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1593. - Resolution: Fixed > Allow SAML2 SPs to override signing/encryption algorithms > - > > Key: SYNCOPE-1593 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1593 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > > Make sure SAML2 SPs in WA can have the ability to present their own > requirements for signing algos, or blocking algos, etc. (i.e. an SP might > require SHA-1 as the signing algorithm, or may want to block it) > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1593) Allow SAML2 SPs to override signing/encryption algorithms
Misagh Moayyed created SYNCOPE-1593: --- Summary: Allow SAML2 SPs to override signing/encryption algorithms Key: SYNCOPE-1593 URL: https://issues.apache.org/jira/browse/SYNCOPE-1593 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Make sure SAML2 SPs in WA can have the ability to present their own requirements for signing algos, or blocking algos, etc. (i.e. an SP might require SHA-1 as the signing algorithm, or may want to block it) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1589) REST APIs to support WebAuthN device registration
[ https://issues.apache.org/jira/browse/SYNCOPE-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1589. - Resolution: Fixed > REST APIs to support WebAuthN device registration > - > > Key: SYNCOPE-1589 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1589 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > > Design REST APIs, etc to allow device registration requests via WebAuthN MFA. > This would be, in concept, similar to how GAUTH works. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1589) REST APIs to support WebAuthN device registration
Misagh Moayyed created SYNCOPE-1589: --- Summary: REST APIs to support WebAuthN device registration Key: SYNCOPE-1589 URL: https://issues.apache.org/jira/browse/SYNCOPE-1589 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Design REST APIs, etc to allow device registration requests via WebAuthN MFA. This would be, in concept, similar to how GAUTH works. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1587) Enable Web AuthN support for WA
[ https://issues.apache.org/jira/browse/SYNCOPE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1587. - Resolution: Fixed > Enable Web AuthN support for WA > --- > > Key: SYNCOPE-1587 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1587 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Modify the Syncope WA build to turn on basic support for FIDO2/web-authn. > Doing so allows the WA module to enable Web AuthN support for MFA requests, > depending on available MFA triggers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1587) Enable Web AuthN support for WA
[ https://issues.apache.org/jira/browse/SYNCOPE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1587: Description: Modify the Syncope WA build to turn on basic support for FIDO2/web-authn. Doing so allows the WA module to enable Web AuthN support for MFA requests, depending on available MFA triggers. (was: Modify the build to turn on basic support for FIDO2/web-authn) > Enable Web AuthN support for WA > --- > > Key: SYNCOPE-1587 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1587 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Modify the Syncope WA build to turn on basic support for FIDO2/web-authn. > Doing so allows the WA module to enable Web AuthN support for MFA requests, > depending on available MFA triggers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1587) Enable webauthn support for WA
Misagh Moayyed created SYNCOPE-1587: --- Summary: Enable webauthn support for WA Key: SYNCOPE-1587 URL: https://issues.apache.org/jira/browse/SYNCOPE-1587 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Modify the build to turn on basic support for FIDO2/web-authn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1587) Enable Web AuthN support for WA
[ https://issues.apache.org/jira/browse/SYNCOPE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1587: Summary: Enable Web AuthN support for WA (was: Enable webauthn support for WA) > Enable Web AuthN support for WA > --- > > Key: SYNCOPE-1587 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1587 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Modify the build to turn on basic support for FIDO2/web-authn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1580) Design WA REST APIs to configure configuration properties
[ https://issues.apache.org/jira/browse/SYNCOPE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1580. - Resolution: Fixed > Design WA REST APIs to configure configuration properties > - > > Key: SYNCOPE-1580 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1580 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Define REST endpoints and relevant data structures allowing WA to set and > configure properties such as the OIDC issuer, etc. The endpoints should be > sufficiently protected so they can be called from the command-line or the > admin-UI once UI support is built. Once a property value is stored, WA should > be asked to refresh its context to fetch the setting and resume without > having to rebuild or restart the container, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1580) Design WA REST APIs to configure configuration properties
Misagh Moayyed created SYNCOPE-1580: --- Summary: Design WA REST APIs to configure configuration properties Key: SYNCOPE-1580 URL: https://issues.apache.org/jira/browse/SYNCOPE-1580 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Define REST endpoints and relevant data structures allowing WA to set and configure properties such as the OIDC issuer, etc. The endpoints should be sufficiently protected so they can be called from the command-line or the admin-UI once UI support is built. Once a property value is stored, WA should be asked to refresh its context to fetch the setting and resume without having to rebuild or restart the container, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1577) Support CAS-enabled client applications
[ https://issues.apache.org/jira/browse/SYNCOPE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1577. - Resolution: Fixed > Support CAS-enabled client applications > --- > > Key: SYNCOPE-1577 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1577 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Allow WA to act as a CAS-enabled identity provider for CAS-enabled client > applications using the CAS protocol -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1577) Support CAS-enabled client applications
Misagh Moayyed created SYNCOPE-1577: --- Summary: Support CAS-enabled client applications Key: SYNCOPE-1577 URL: https://issues.apache.org/jira/browse/SYNCOPE-1577 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Allow WA to act as a CAS-enabled identity provider for CAS-enabled client applications using the CAS protocol -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1571) Support U2F MFA tokens/requests via REST APIs
[ https://issues.apache.org/jira/browse/SYNCOPE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1571. - Resolution: Fixed > Support U2F MFA tokens/requests via REST APIs > - > > Key: SYNCOPE-1571 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1571 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > U2F mfa authentication requests/responses should be managed via dedicated > endpoints and REST APIs, similar to how GoogleAuth functionality works in WA. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1570) Support U2F device registration via REST APIs
[ https://issues.apache.org/jira/browse/SYNCOPE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1570. - Resolution: Fixed > Support U2F device registration via REST APIs > - > > Key: SYNCOPE-1570 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1570 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Allow the WA module to handle device registrations for U2F MFA via dedicated > APIs and REST endpoints. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1571) Support U2F MFA tokens/requests via REST APIs
Misagh Moayyed created SYNCOPE-1571: --- Summary: Support U2F MFA tokens/requests via REST APIs Key: SYNCOPE-1571 URL: https://issues.apache.org/jira/browse/SYNCOPE-1571 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 U2F mfa authentication requests/responses should be managed via dedicated endpoints and REST APIs, similar to how GoogleAuth functionality works in WA. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1570) Support U2F device registration via REST APIs
Misagh Moayyed created SYNCOPE-1570: --- Summary: Support U2F device registration via REST APIs Key: SYNCOPE-1570 URL: https://issues.apache.org/jira/browse/SYNCOPE-1570 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Allow the WA module to handle device registrations for U2F MFA via dedicated APIs and REST endpoints. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1556) Allow WA as OIDC OP to fetch JWKS over REST
[ https://issues.apache.org/jira/browse/SYNCOPE-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1556. - Resolution: Fixed > Allow WA as OIDC OP to fetch JWKS over REST > --- > > Key: SYNCOPE-1556 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1556 > Project: Syncope > Issue Type: Sub-task > Components: core, wa >Affects Versions: 3.0.0 >Reporter: Matteo Alessandroni > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > WA when running as an OIDC OP must be able to fetch its JWKS from a rest > endpoint -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SYNCOPE-1556) Allow WA as OIDC OP to fetch JWKS over REST
[ https://issues.apache.org/jira/browse/SYNCOPE-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed reassigned SYNCOPE-1556: --- Assignee: Misagh Moayyed (was: Matteo Alessandroni) > Allow WA as OIDC OP to fetch JWKS over REST > --- > > Key: SYNCOPE-1556 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1556 > Project: Syncope > Issue Type: Sub-task > Components: core, wa >Affects Versions: 3.0.0 >Reporter: Matteo Alessandroni > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > WA when running as an OIDC OP must be able to fetch its JWKS from a rest > endpoint -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1566) Manage device registration records for GoogleAuthMFA
[ https://issues.apache.org/jira/browse/SYNCOPE-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1566. - Resolution: Fixed > Manage device registration records for GoogleAuthMFA > > > Key: SYNCOPE-1566 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1566 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > The Google Authenticator MFA functionality allows users to register/onboard > devices to then begin with MFA and TOTP codes, etc. These device records > should be stored in Syncope managed via dedicated endpoints and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [PROPOSAL] Get rid of JAXB (2nd attempt)
+1. Excellent work. You had me at "Get rid of JAXB" :) --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Friday, May 29, 2020 5:52:25 PM > Subject: [PROPOSAL] Get rid of JAXB (2nd attempt) > Hi all, > about 3.5 years after my first attempt [1], here I am again to propose to > replace JAXB for XML payloads management, still with Jackson Dataformat XML > [2]. > > During our first discussion, the main objection was about WADL being removed, > for at least two reasons: > > 1. client code generation from WADL > 2. WADL being used for REST services documentation [3] > > Compared to 3.5 years ago, I think it's a rather shared opinion that OpenAPI > is > a very solid mean for client-code generation, with wide range of languages > being supported. > Moreover, we have been using Swagger UI for REST service since quite some > time, > with very satisfactory results. > > For the reasons above, I have submitted a PR [4] against master branch, which: > > 1. removes JAXB completely > 2. replaces REST services documentation with Swagger UI > 3. adds application/xml ITs to Travis, thus fixing SYNCOPE-1565 for master > branch > > Please have a look and review, thanks. > Regards. > > [1] > https://lists.apache.org/thread.html/abffcf286c15ff622093916287948b40d86f645b6feae4befa65f1d3%40%3Cdev.syncope.apache.org%3E > [2] https://github.com/FasterXML/jackson-dataformat-xml > [3] http://syncope.apache.org/rest/2.1/index.html > [4] https://github.com/apache/syncope/pull/192 > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
[jira] [Resolved] (SYNCOPE-1562) Handle OTP records for GoogleAuthN MFA
[ https://issues.apache.org/jira/browse/SYNCOPE-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1562. - Resolution: Fixed > Handle OTP records for GoogleAuthN MFA > -- > > Key: SYNCOPE-1562 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1562 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > The Google Authenticator MFA functionality allows users to register/onboard > devices to then begin with MFA and TOTP codes, etc. These tokens/codes should > be stored in Syncope managed via dedicated endpoints and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1566) Manage device registration records for GoogleAuthMFA
Misagh Moayyed created SYNCOPE-1566: --- Summary: Manage device registration records for GoogleAuthMFA Key: SYNCOPE-1566 URL: https://issues.apache.org/jira/browse/SYNCOPE-1566 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 The Google Authenticator MFA functionality allows users to register/onboard devices to then begin with MFA and TOTP codes, etc. These device records should be stored in Syncope managed via dedicated endpoints and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1562) Handle OTP records for GoogleAuthN MFA
[ https://issues.apache.org/jira/browse/SYNCOPE-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1562: Description: The Google Authenticator MFA functionality allows users to register/onboard devices to then begin with MFA and TOTP codes, etc. These tokens/codes should be stored in Syncope managed via dedicated endpoints and APIs. (was: The Google Authenticator MFA functionality allows users to register/onboard devices to then begin with MFA and TOTP codes, etc. These registration records should be stored in Syncope managed via dedicated endpoints and APIs.) Summary: Handle OTP records for GoogleAuthN MFA (was: Handle device registration records for GoogleAuthN MFA) > Handle OTP records for GoogleAuthN MFA > -- > > Key: SYNCOPE-1562 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1562 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > The Google Authenticator MFA functionality allows users to register/onboard > devices to then begin with MFA and TOTP codes, etc. These tokens/codes should > be stored in Syncope managed via dedicated endpoints and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1562) Handle device registration records for GoogleAuthN MFA
Misagh Moayyed created SYNCOPE-1562: --- Summary: Handle device registration records for GoogleAuthN MFA Key: SYNCOPE-1562 URL: https://issues.apache.org/jira/browse/SYNCOPE-1562 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 The Google Authenticator MFA functionality allows users to register/onboard devices to then begin with MFA and TOTP codes, etc. These registration records should be stored in Syncope managed via dedicated endpoints and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1559) Allow WA Google Auth MFA settings to become reloadable
[ https://issues.apache.org/jira/browse/SYNCOPE-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1559. - Resolution: Fixed > Allow WA Google Auth MFA settings to become reloadable > -- > > Key: SYNCOPE-1559 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1559 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > The configuration of google authentication module for MFA in WA cannot be > refreshed today when settings change such as window-size, time-step, etc. > This is because the bean definition in WA/CAS that is built based on such > settings is not marked as RefreshScope, because the implementation class for > the GoogleAuthenticator component in WA/CAS belongs to a 3rd party library > that has marked the class as final. Final classes cannot be proxied via > RefreshScope. > Changes mainly will be done in CAS to find a workaround to mark the > GoogleAuthenticator bean with RefreshScope. When done, WA will receive the > fix for free automatically. > Also other beans in the same module should be reviewed to make sure all > required beans can be reloadable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1558) Configure WA delegated authn module to SAML IdPs via REST
[ https://issues.apache.org/jira/browse/SYNCOPE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1558. - Resolution: Fixed > Configure WA delegated authn module to SAML IdPs via REST > - > > Key: SYNCOPE-1558 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1558 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > When WA is configured to hand off authentication to an external SAML2 > identity provider via pac4j, pac4j expects a java keystore to be > created/present on disk that will be used by WA as a SAML SP to interact with > the IDP and to generate metadata, sign responses, etc. This keystore is > expected to be found on disk, and pac4j does not allow other options for > producing/fetching the keystore via REST. > Also, a number of other artifacts such as generation of SP metadata, etc > should be configurable over rest. > > Task is: > * Allow pac4j to open up its api/configuration to allow for keystore > fetching over rest > * Modify WA to use this configuration and produce keystore data over rest. > > Note that a similar and separate task may be created to handle the same > matter with delegated authn to OIDC OPs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1559) Allow WA Google Auth MFA settings to become reloadable
Misagh Moayyed created SYNCOPE-1559: --- Summary: Allow WA Google Auth MFA settings to become reloadable Key: SYNCOPE-1559 URL: https://issues.apache.org/jira/browse/SYNCOPE-1559 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 The configuration of google authentication module for MFA in WA cannot be refreshed today when settings change such as window-size, time-step, etc. This is because the bean definition in WA/CAS that is built based on such settings is not marked as RefreshScope, because the implementation class for the GoogleAuthenticator component in WA/CAS belongs to a 3rd party library that has marked the class as final. Final classes cannot be proxied via RefreshScope. Changes mainly will be done in CAS to find a workaround to mark the GoogleAuthenticator bean with RefreshScope. When done, WA will receive the fix for free automatically. Also other beans in the same module should be reviewed to make sure all required beans can be reloadable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SYNCOPE-1496) Add integration tests for DBMSes via Docker
[ https://issues.apache.org/jira/browse/SYNCOPE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed reassigned SYNCOPE-1496: --- Assignee: Francesco Chicchiriccò (was: Misagh Moayyed) > Add integration tests for DBMSes via Docker > --- > > Key: SYNCOPE-1496 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1496 > Project: Syncope > Issue Type: Sub-task > Components: build-tools >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 3.0.0 > > > Integration tests for DBMSes should be turned on and added to Travis CI as an > independant job: > [https://syncope.apache.org/building#DBMSes] > This will of course require pulling down relevant docker images for each > build, and each DBMS may require to be its own job to avoid timeouts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Troubles with release:prepare
I have run into this before, but only when: 1. Running a command-prompt on windows. 2. Running a bash on windows, using the likes mingw or babun In my case, this was caused by a number of things: 1. Bad ssh-agent that could not communicate correctly with git. 2. Somehow, the release plugin thought I was not running commands from the project working directory. 3. Very old versions of git. 4. Weird shell issues. I could never truly figure out if the issue was windows-specific with maven, or some other combination of things. --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Sunday, May 3, 2020 4:26:01 PM > Subject: Re: [DISCUSS] Troubles with release:prepare > On 03/05/20 11:20, Jean-Baptiste Onofre wrote: >> Hi Francesco, >> >> Is scm section up to date ? > > Yes, it is based on gitbox.apache.org and has not actually changed since > 2.1.5 / > 2.0.14, e.g. last time that release:prepare worked as usual. > > Regards. > >>> Le 3 mai 2020 à 09:50, Francesco Chicchiriccò a écrit >>> : >>> >>> Hi all, >>> during the recent release process for 2.0.15 and 2.1.6 I have been >>> following the >>> steps in [1] as usual. >>> >>> Unfortunately, when I arrived to launch the release:prepare step, I could >>> not >>> move forward as the Maven Release plugin, after asking for version to >>> release >>> and next development version to set, was not effectively advancing the POM >>> files. >>> >>> The execution of >>> >>> mvn -P apache-release release:prepare -Darguments="-P all,docker >>> -DbuildNumber=syncope-2.1.6" >>> >>> left the source files set to 2.1.6-SNAPSHOT and thus produced all artifacts >>> with >>> such version, not 2.1.6. (Same happened with 2.0.15). >>> >>> After struggling for some time, I finally came to decision to manually >>> replicate >>> the various steps normally performed by release:prepare [2]: fortunately, >>> this >>> approach was effective, and I could also continue following [1], including >>> the >>> release:perform step. >>> >>> I took some notes of the manual process in [3]. >>> >>> Now I was wondering: what could possibly be the reason of the bad >>> functioning of >>> release:prepare? I even tried with older Release plugin and Maven versions: >>> no >>> luck. >>> >>> As last resort we can always adjust [1] with content from [3], but I'd >>> rather >>> give release:prepare a chance. >>> >>> WDYT? >>> Regards. >>> >>> [1] http://syncope.apache.org/release-process >>> [2] >>> http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html >>> [3] https://gist.github.com/ilgrosso/b2abd6674290d6fe144704dffbeda418 > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-1558) Configure WA delegated authn module to SAML IdPs via REST
[ https://issues.apache.org/jira/browse/SYNCOPE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095519#comment-17095519 ] Misagh Moayyed commented on SYNCOPE-1558: - PR finalized and ready. 4.0.1 SNAPSHOT of pac4j should contain the change, and the change is pushed into the next snapshot release of CAS. Next, will fine-tune the WA configuration with the next CAS snapshot to take advantage of latest pac4j changes for SAML IDP config. > Configure WA delegated authn module to SAML IdPs via REST > - > > Key: SYNCOPE-1558 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1558 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > When WA is configured to hand off authentication to an external SAML2 > identity provider via pac4j, pac4j expects a java keystore to be > created/present on disk that will be used by WA as a SAML SP to interact with > the IDP and to generate metadata, sign responses, etc. This keystore is > expected to be found on disk, and pac4j does not allow other options for > producing/fetching the keystore via REST. > Also, a number of other artifacts such as generation of SP metadata, etc > should be configurable over rest. > > Task is: > * Allow pac4j to open up its api/configuration to allow for keystore > fetching over rest > * Modify WA to use this configuration and produce keystore data over rest. > > Note that a similar and separate task may be created to handle the same > matter with delegated authn to OIDC OPs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Jquery version on 2.1.x/2.0.x
Tested the upgrade to jQuery 3.5.0. No issues. --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Thursday, April 23, 2020 6:04:10 PM > Subject: Re: Jquery version on 2.1.x/2.0.x > On 23/04/20 15:31, Misagh Moayyed wrote: >> In the same vein, I'd like to update the master branch to use jQuery 3.5.0. >> While optional for now, this will soon (1-2 days) become a requirement for >> the >> WA module to function correctly. Local testing shows that the upgrade is >> innocuous. > > If the REST service docs showing at > > http://localhost:9080/syncope/ > > works still fine with jQuery 3.5.0, then +1 for me to go ahead and upgrade on > master. > > Console and Enduser do use jQuery via Wicket, so no issues from those. > > Regards. > >> - Original Message - >>> From: "Colm O hEigeartaigh" >>> To: "dev" >>> Sent: Thursday, April 23, 2020 12:10:28 PM >>> Subject: Re: Jquery version on 2.1.x/2.0.x >>> That's great, thanks! >>> >>> Colm. >>> >>> On Thu, Apr 23, 2020 at 8:35 AM Francesco Chicchiriccò >>> wrote: >>> >>>> On 23/04/20 08:58, Francesco Chicchiriccò wrote: >>>>> On 23/04/20 08:51, Colm O hEigeartaigh wrote: >>>>>> Is it possible to update the JQuery version on 2.1.x/2.0.x to the same >>>>>> version as on master? (3.4.1). It seems the existing version is >>>> vulnerable >>>>>> to https://nvd.nist.gov/vuln/detail/CVE-2019-11358 >>>>> Hi Colm, >>>>> I don't see issue. Let me do some local tests to confirm and I'll revert >>>> here. >>>>> Regards. >>>> Found no issues, proceeded with upgrade: >>>> >>>> * 2_0_X: >>>> https://github.com/apache/syncope/commit/8ec6c23498aa058860024a2940b8d3104b4be7d6 >>>> * 2_1_X: >>>> https://github.com/apache/syncope/commit/40bb5d7fe3790a5a66743d8473de0976bb2780b7 >>>> >>>> Regards. >>>> >>>> -- >>>> Francesco Chicchiriccò >>>> >>>> Tirasa - Open Source Excellence >>>> http://www.tirasa.net/ >>>> >>>> Member at The Apache Software Foundation >>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail >>>> http://home.apache.org/~ilgrosso/ >>>> > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-1558) Configure WA delegated authn module to SAML IdPs via REST
[ https://issues.apache.org/jira/browse/SYNCOPE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091597#comment-17091597 ] Misagh Moayyed commented on SYNCOPE-1558: - Initial pull request to pac4j: [https://github.com/pac4j/pac4j/pull/1577] > Configure WA delegated authn module to SAML IdPs via REST > - > > Key: SYNCOPE-1558 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1558 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > When WA is configured to hand off authentication to an external SAML2 > identity provider via pac4j, pac4j expects a java keystore to be > created/present on disk that will be used by WA as a SAML SP to interact with > the IDP and to generate metadata, sign responses, etc. This keystore is > expected to be found on disk, and pac4j does not allow other options for > producing/fetching the keystore via REST. > Also, a number of other artifacts such as generation of SP metadata, etc > should be configurable over rest. > > Task is: > * Allow pac4j to open up its api/configuration to allow for keystore > fetching over rest > * Modify WA to use this configuration and produce keystore data over rest. > > Note that a similar and separate task may be created to handle the same > matter with delegated authn to OIDC OPs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Jquery version on 2.1.x/2.0.x
In the same vein, I'd like to update the master branch to use jQuery 3.5.0. While optional for now, this will soon (1-2 days) become a requirement for the WA module to function correctly. Local testing shows that the upgrade is innocuous. --Misagh - Original Message - > From: "Colm O hEigeartaigh" > To: "dev" > Sent: Thursday, April 23, 2020 12:10:28 PM > Subject: Re: Jquery version on 2.1.x/2.0.x > That's great, thanks! > > Colm. > > On Thu, Apr 23, 2020 at 8:35 AM Francesco Chicchiriccò > wrote: > >> On 23/04/20 08:58, Francesco Chicchiriccò wrote: >> > On 23/04/20 08:51, Colm O hEigeartaigh wrote: >> >> Is it possible to update the JQuery version on 2.1.x/2.0.x to the same >> >> version as on master? (3.4.1). It seems the existing version is >> vulnerable >> >> to https://nvd.nist.gov/vuln/detail/CVE-2019-11358 >> > Hi Colm, >> > I don't see issue. Let me do some local tests to confirm and I'll revert >> here. >> > >> > Regards. >> >> Found no issues, proceeded with upgrade: >> >> * 2_0_X: >> https://github.com/apache/syncope/commit/8ec6c23498aa058860024a2940b8d3104b4be7d6 >> * 2_1_X: >> https://github.com/apache/syncope/commit/40bb5d7fe3790a5a66743d8473de0976bb2780b7 >> >> Regards. >> >> -- >> Francesco Chicchiriccò >> >> Tirasa - Open Source Excellence >> http://www.tirasa.net/ >> >> Member at The Apache Software Foundation >> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail >> http://home.apache.org/~ilgrosso/ >>
[jira] [Created] (SYNCOPE-1558) Configure WA delegated authn module to SAML IdPs via REST
Misagh Moayyed created SYNCOPE-1558: --- Summary: Configure WA delegated authn module to SAML IdPs via REST Key: SYNCOPE-1558 URL: https://issues.apache.org/jira/browse/SYNCOPE-1558 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 When WA is configured to hand off authentication to an external SAML2 identity provider via pac4j, pac4j expects a java keystore to be created/present on disk that will be used by WA as a SAML SP to interact with the IDP and to generate metadata, sign responses, etc. This keystore is expected to be found on disk, and pac4j does not allow other options for producing/fetching the keystore via REST. Also, a number of other artifacts such as generation of SP metadata, etc should be configurable over rest. Task is: * Allow pac4j to open up its api/configuration to allow for keystore fetching over rest * Modify WA to use this configuration and produce keystore data over rest. Note that a similar and separate task may be created to handle the same matter with delegated authn to OIDC OPs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1553) Fetch WA auth modules & map to properties during bootstrap
[ https://issues.apache.org/jira/browse/SYNCOPE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1553. - Resolution: Fixed > Fetch WA auth modules & map to properties during bootstrap > -- > > Key: SYNCOPE-1553 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1553 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > > Authentication modules, etc need to be fetched via WA bootstrap using the new > REST APIs and translated into WA configuration properties. This should allow > context-refresh events to successfully activate those authentication modules > for login. > Example use case would be: > * define LDAP authentication module > * fetch module settings in WA on startup/bootstrap > * refresh context > * login using sample LDAP credentials -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Time to cut 2.1.6 / 2.0.15?
+1 --Misagh - Original Message - > From: "Andrea Patricelli" > To: "dev" > Sent: Wednesday, April 15, 2020 11:41:27 AM > Subject: Re: Time to cut 2.1.6 / 2.0.15? > Good morning all, > > for me definitely yes. > > Best regards, > Andrea > > Il 14/04/20 11:58, Francesco Chicchiriccò ha scritto: >> Hi there, >> I think it's about time to start preparing Syncope 2.1.6 / 2.0.15 (several >> fixes >> and improvement, time passed since previous releases, ..). >> >> If you have any pending change or fix, please either finalize as soon as >> possible or let's postpone. >> >> WDYT? >> > -- > Dott. Andrea Patricelli > Tel. +39 3204524292 > > Engineer @ Tirasa S.r.l. > Viale Vittoria Colonna 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 085973 > http://www.tirasa.net > > Apache Syncope PMC Member
[jira] [Created] (SYNCOPE-1553) Fetch WA auth modules & map to properties during bootstrap
Misagh Moayyed created SYNCOPE-1553: --- Summary: Fetch WA auth modules & map to properties during bootstrap Key: SYNCOPE-1553 URL: https://issues.apache.org/jira/browse/SYNCOPE-1553 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Authentication modules, etc need to be fetched via WA bootstrap using the new REST APIs and translated into WA configuration properties. This should allow context-refresh events to successfully activate those authentication modules for login. Example use case would be: * define LDAP authentication module * fetch module settings in WA on startup/bootstrap * refresh context * login using sample LDAP credentials -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1552) Allow WA audits to be stored in Syncope
[ https://issues.apache.org/jira/browse/SYNCOPE-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1552. - Resolution: Fixed [https://github.com/apache/syncope/pull/174] > Allow WA audits to be stored in Syncope > --- > > Key: SYNCOPE-1552 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1552 > Project: Syncope > Issue Type: Sub-task > Components: wa >Affects Versions: 3.0.0 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 3.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Web Access Audits are presently handled by default via Sl4fj and written to > log files. Audit events should be handled and managed by Syncope itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1552) Allow WA audits to be stored in Syncope
Misagh Moayyed created SYNCOPE-1552: --- Summary: Allow WA audits to be stored in Syncope Key: SYNCOPE-1552 URL: https://issues.apache.org/jira/browse/SYNCOPE-1552 Project: Syncope Issue Type: Sub-task Components: wa Affects Versions: 3.0.0 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 3.0.0 Web Access Audits are presently handled by default via Sl4fj and written to log files. Audit events should be handled and managed by Syncope itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SYNCOPE-1497) Upgrade to Wicket 9
[ https://issues.apache.org/jira/browse/SYNCOPE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed reassigned SYNCOPE-1497: --- Assignee: Francesco Chicchiriccò (was: Misagh Moayyed) > Upgrade to Wicket 9 > --- > > Key: SYNCOPE-1497 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1497 > Project: Syncope > Issue Type: Task > Components: console, enduser >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > See https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+9.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1506) Merge Users
[ https://issues.apache.org/jira/browse/SYNCOPE-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1506. - Resolution: Fixed Feature is (and will be) available in 2.1 and the 3.0 release lines. > Merge Users > --- > > Key: SYNCOPE-1506 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1506 > Project: Syncope > Issue Type: New Feature > Components: console, core >Reporter: Francesco Chicchiriccò > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Following SYNCOPE-957, this issue is to provide ability to take two distinct > Users as input and to produce an User with a Linked Account as output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026722#comment-17026722 ] Misagh Moayyed commented on SYNCOPE-1511: - new PR to ensure manage history is displayed or hidden in the right panels. > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: console, core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Few suggestions on XML content export
Hey Team, Wanted to share a couple of ideas with you to see if they may be worth following up with JIRAs and PRs: - While working on Syncope, often times I end up making a change in the admin console (i.e. adding a configuration parameter), and then I export/download the configuration XML, pick out the new changes from the saved XML file to put into my own version of the MasterContent.xml. This works great with one small issue and that is, I have to download and the save file. It would be more comfortable if Syncope offered a way to just view the XML configuration with an export option separately. - Similarly, it would be even better if I the admin console allowed one to view the XML configuration of an individual item. For example, I would be interested in seeing the XML representation of the new configuration parameter I added in the admin console, or it might be a user object, group, etc. WDYT? --Misagh
Re: [SYNCOPE-163] PR #103 design notes
Happy 2020, team! Thanks much for the notes, Marco. I have had a chance to review the design notes and the insofar implementation and have a few proposals to discuss: - "Chain Authentication" as the default authentication type Narrowing down the types to two only, where default Syncope authentication then becomes a standard module in the chain that is present an active by default. This allows Syncope authentication to be used in the chain along with others, (i.e. Use user+password with LDAP/DB, and if not found, fall back into Syncope). - Success criteria for the chain? Seems like the authn policy also needs to establish a success criteria for the chain of authN modules that execute. As in, "Should we consider it a successful authn event if all modules can validate the user? Or maybe only some of them?", etc. - Order-able authentication chain? My assumption is that authN modules registered in a chain are or should be orderable and sortable; for discussion's sake, let's say by a numeric value assigned to the module. Such that, when we go through the chain, sort it by an order, and then begin to execute each module to find the user. - Separation of MFA vs Primary AuthN modules I think MFA is most usually taken as 2FA. We'd have some number of modules that can support primary AuthN (first leg), and then we'd have a second set of MFA modules capable of responding to the second leg (and in theory more). So you login with X509 and then FIDO, or you login with Syncope and then OTP. If the chain is sortable/orderable, this would mean that the two sets (Primary AuthN & MFA AuthN modules) should be recognized differently by the chain, because you wouldn't want a scenario where you do FIDO first, and then LDAP. That seems odd. - Use JAAS for most authentication modules? It might be possible to take advantage of native JAAS functionality for a number of authN modules, such as LDAP, DB, Kerberos. I am not sure if we'd have to create new code for, say, LDAP authn where we could just take advantage of native JAAS? - WebAuthN should include U2F AFAIK, WebAuthN should auto-support U2F. I don't think we'd have a use case where someone would want to deploy Syncope with just U2F. Seems odd to me. - Policy assigned to realm? My understanding so far is that each realm is assigned an authentication policy, and the policy describes the "types of authentications that can be used in, say, a chain. I think this might require Realm selection first (i.e. in the UI) so we can look up the authentication policy, right? If so, the UI likely needs to be changed to implement some sort of flow where you ask for the Realm first, look up the policy and then decide the type of credentials that should be asked from the user. (userid+password, x509 cert, etc). In the case of MFA, we also need to figure out some sort of identifier (not always the username; there may not be a username) from the first leg that can be used to link the user to the MFA step. A typical example might be: - Pick Master realm - AuthN policy says to do LDAP and OTP - Show username+password for LDAP - On success, grab username (identifier) and locate device record for OTP - Registration flow for OTP if device not found based on the username (identifier) - Do OTP - Proceed. Am I on the right path? Any of this make sense? On a semi-related note, I have sort of had an internal/personal TODO item to add CAS SP support to Syncope (sort of like what exists for SAML2 SPs). I am not sure how popular or relevant this might be, and I was planning to do this just to learn Syncope+UI better. However, if this is something useful for Syncope, we could likely take that into consideration as well. Overall, the task here is a very large piece of work and so if agreed, the CAS piece can become a sub-task somewhere down the road. --Misagh - Original Message - > From: "Marco Di Sabatino Di Diodoro" > To: "dev" > Sent: Tuesday, September 3, 2019 11:46:50 AM > Subject: Re: [SYNCOPE-163] PR #103 design notes > Il 03/09/19 09:34, Francesco Chicchiriccò ha scritto: >> On 03/09/19 09:05, Misagh Moayyed wrote: >>> Hi Marco, >>> >>> I have begun to learn and study SYNCOPE-163 for which there is this pending >>> PR >>> by you: >>> https://github.com/apache/syncope/pull/103 >>> >>> Would you mind putting together a few notes/paragraphs on the high level >>> design, >>> abstractions and intention of each component on the wiki? Or if there is one >>> already, could you point me to it please? Any sort of documentation that you >>> can spare on the design would be most welcome, as time allows. >> Hi Misagh, >> welcome to Apache Syncope. >> >> Marco, I created >> >> https://cwik
[jira] [Assigned] (SYNCOPE-1506) Merge Users
[ https://issues.apache.org/jira/browse/SYNCOPE-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed reassigned SYNCOPE-1506: --- Assignee: Misagh Moayyed > Merge Users > --- > > Key: SYNCOPE-1506 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1506 > Project: Syncope > Issue Type: New Feature > Components: console, core >Reporter: Francesco Chicchiriccò > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > > Following SYNCOPE-957, this issue is to provide ability to take two distinct > Users as input and to produce an User with a Linked Account as output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Automating Syncope's dependency updates
Sure, will do. Thanks everyone. --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Monday, December 16, 2019 12:22:45 PM > Subject: Re: Automating Syncope's dependency updates > Hi Misagh, > it seems we have some consensus here, please go ahead and open an issue on > > https://issues.apache.org/jira/browse/INFRA > > about this topic, thanks. > > Regards. > > On 11/12/19 15:13, Francesco Chicchiriccò wrote: >> Hi Misagh, >> renovatebot looks interesting and worth at least to explore the possibility >> to >> add it at project's (rather than committer's level). >> >> +1 to go ahead and ask Infra team about it. >> Regards. >> >> On 11/12/19 15:00, Misagh Moayyed wrote: >>> Hey Team, >>> >>> I suspect most know about this sort of thing, but I thought to share this >>> with >>> you: >>> https://github.com/renovatebot/renovate >>> >>> I think this is a useful tool to allow a Github project such as Syncope to >>> automatically receive dependency updates and become self sufficient. It will >>> attempt to parse the project's dependencies/pom and will then begin to issue >>> pull requests with relevant updates. Its schedule, update policy and >>> inclusion/exclusion rules can all be controlled via a .renovate JSON file. >>> >>> It can run in two ways: >>> >>> 1- As a GitHub app, which would be installed for the Apache org on Github >>> and >>> enabled for select repositories, such as Syncope. This option requires >>> coordination/permission from Apache infra, and updates are then automatic. >>> >>> 2- As a CLI tool, where a committer's personal access token is passed as a >>> command-line argument, and the tool can run as part of CI. This option >>> probably >>> does not require anything from Apache infra [?], and updates can be >>> cancelled >>> as part of the CI job that runs the tool. >>> >>> I am not sure what the CLA policy would be for bots; the second option >>> probably >>> [?] covers this, as PRs are issued on behalf of the committer whose AT is >>> used. >>> Either way, it seems like we need clarification from Apache infra. >>> >>> This is an example of a pull request by the bot: >>> https://github.com/Jasig/uPortal/pull/1849 >>> >>> This is an example of the bot's JSON configuration file: >>> https://github.com/Jasig/uPortal/blob/master/renovate.json >>> >>> How do you feel about this? Is this a good option to pursue and follow up? >>> >>> The bot also has the ability to rebase PRs, and can also take over the >>> merging >>> process automatically if CI passes or other rules allow. (At some point in >>> the >>> future, I think it will also gain the ability to travel back in time and >>> kill >>> Sarah Connor [1], but that has yet to be fully verified.) >>> >>> --Misagh >>> >>> [1] https://www.wikiwand.com/en/Sarah_Connor_(Terminator) > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
Re: [PROPOSAL] Joining the OpenJDK Quality Outreach initiative
+1 --Misagh - Original Message - > From: "Matteo Alessandroni" > To: "dev" > Sent: Monday, December 16, 2019 6:16:26 PM > Subject: Re: [PROPOSAL] Joining the OpenJDK Quality Outreach initiative > Hi, > > +1 for me! > > Regards, > Matteo > > On 16/12/19 13:09, Francesco Chicchiriccò wrote: >> Hi all, >> we have the chance to join the OpenJDK Quality Outreach initiative [1]. >> >> They try to encourage popular open source projects to test their releases on >> latest OpenJDK Early Access builds (i.e. JDK 14 -ea, atm), by providing them >> with regular information describing new builds, their features, and making >> sure >> that their bug reports and feedback land in the right hands. So in that >> sense, >> being able to expand the set of projects testing against the latest JDK Early >> Access builds across many domains >> can help detect issues that would otherwise be only detected once a release >> is >> shipped. >> >> As you can see from [1], there are several ASF projects listed there, so I >> believe there is nothing preventing us to do so. >> >> Since our master branch builds are based on OpenJDK 11, I think the only >> requirement left would be to set up a CI job against OpenJDK 14-EA, which is >> definitely something we can afford. >> >> WDYT? >> Regards. >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach
Automating Syncope's dependency updates
Hey Team, I suspect most know about this sort of thing, but I thought to share this with you: https://github.com/renovatebot/renovate I think this is a useful tool to allow a Github project such as Syncope to automatically receive dependency updates and become self sufficient. It will attempt to parse the project's dependencies/pom and will then begin to issue pull requests with relevant updates. Its schedule, update policy and inclusion/exclusion rules can all be controlled via a .renovate JSON file. It can run in two ways: 1- As a GitHub app, which would be installed for the Apache org on Github and enabled for select repositories, such as Syncope. This option requires coordination/permission from Apache infra, and updates are then automatic. 2- As a CLI tool, where a committer's personal access token is passed as a command-line argument, and the tool can run as part of CI. This option probably does not require anything from Apache infra [?], and updates can be cancelled as part of the CI job that runs the tool. I am not sure what the CLA policy would be for bots; the second option probably [?] covers this, as PRs are issued on behalf of the committer whose AT is used. Either way, it seems like we need clarification from Apache infra. This is an example of a pull request by the bot: https://github.com/Jasig/uPortal/pull/1849 This is an example of the bot's JSON configuration file: https://github.com/Jasig/uPortal/blob/master/renovate.json How do you feel about this? Is this a good option to pursue and follow up? The bot also has the ability to rebase PRs, and can also take over the merging process automatically if CI passes or other rules allow. (At some point in the future, I think it will also gain the ability to travel back in time and kill Sarah Connor [1], but that has yet to be fully verified.) --Misagh [1] https://www.wikiwand.com/en/Sarah_Connor_(Terminator)
[jira] [Resolved] (SYNCOPE-1523) JPAConnInstanceDAO should be marked as Transactional
[ https://issues.apache.org/jira/browse/SYNCOPE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1523. - Resolution: Fixed > JPAConnInstanceDAO should be marked as Transactional > > > Key: SYNCOPE-1523 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1523 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Minor > Fix For: 2.1.6, 3.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Allow the JPAConnInstanceDAO to be marked as Transactional, specifically for > find and findAuth methods (readOnly) to allow for persistence operations and > calls from components that already may be marked as such. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1523) JPAConnInstanceDAO should be marked as Transactional
Misagh Moayyed created SYNCOPE-1523: --- Summary: JPAConnInstanceDAO should be marked as Transactional Key: SYNCOPE-1523 URL: https://issues.apache.org/jira/browse/SYNCOPE-1523 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 2.1.5 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 2.1.6, 3.0.0 Allow the JPAConnInstanceDAO to be marked as Transactional, specifically for find and findAuth methods (readOnly) to allow for persistence operations and calls from components that already may be marked as such. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1511. - Resolution: Fixed > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: console, core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988813#comment-16988813 ] Misagh Moayyed commented on SYNCOPE-1511: - Small note FTR that the changes will also be cherry-picked into the 3.0/master branch as well. > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: console, core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed resolved SYNCOPE-1511. - Resolution: Fixed > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: console, core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1511: Description: Extract and export audit events for user create / update / etc (and extend support to groups and "any object"s), expose them via dedicated REST interfaces/ops. Also, make sure data can be reviewed in the admin console via a new history tool. This feature shall be cherry-picked into master for 3.0, when ready. was: Configure audit events for user create / update / etc and extend support to groups and "any object"s. Payloads will be stored in the dedicated audit table. This feature shall be cherry-picked into master for 3.0, when ready. > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed >Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1511: Component/s: console > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: console, core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > > Extract and export audit events for user create / update / etc (and extend > support to groups and "any object"s), expose them via dedicated REST > interfaces/ops. Also, make sure data can be reviewed in the admin console via > a new history tool. > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
[ https://issues.apache.org/jira/browse/SYNCOPE-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misagh Moayyed updated SYNCOPE-1511: External issue URL: (was: https://jira.gfs.com/jira/browse/IDAAS-59) > Configure audit events create/update/etc of users, groups, etc > -- > > Key: SYNCOPE-1511 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 > Project: Syncope > Issue Type: New Feature > Components: core >Affects Versions: 2.1.5 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed >Priority: Major > Fix For: 2.1.6, 3.0.0 > > > Configure audit events for user create / update / etc and extend support to > groups and "any object"s. Payloads will be stored in the dedicated audit > table. > > This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SYNCOPE-1511) Configure audit events create/update/etc of users, groups, etc
Misagh Moayyed created SYNCOPE-1511: --- Summary: Configure audit events create/update/etc of users, groups, etc Key: SYNCOPE-1511 URL: https://issues.apache.org/jira/browse/SYNCOPE-1511 Project: Syncope Issue Type: New Feature Components: core Affects Versions: 2.1.5 Reporter: Misagh Moayyed Assignee: Misagh Moayyed Fix For: 2.1.6, 3.0.0 Configure audit events for user create / update / etc and extend support to groups and "any object"s. Payloads will be stored in the dedicated audit table. This feature shall be cherry-picked into master for 3.0, when ready. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Github auto-linking to external resources
I sent an email to Apache infra to request turning on auto-linking to external resources for Syncope on Github. They pointed out this JIRA: https://issues.apache.org/jira/browse/INFRA-19276 Figured I'd share, if you'd like to vote for the issue or watch for updates. This is quite cool, though does have room for improvements to allow detection patterns against PR titles, branches, etc. Nonetheless, here's a demonstration: https://twitter.com/github/status/1183789660142747648 --Misagh
AWS Promotional Credits for Open Source Projects
https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects Might this be useful for Syncope? --Misagh
Re: [DISCUSS] How to replace ianal-maven-plugin?
Thanks, I understand. Unfortunately, I personally do not know of any. --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Monday, October 14, 2019 3:37:32 PM > Subject: Re: [DISCUSS] How to replace ianal-maven-plugin? > On 14/10/19 13:15, Misagh Moayyed wrote: >> I think the license-maven-plugin does have the ability to generate license >> headers or remove/update them. Is that not the behavior we are looking for, >> or >> do I misunderstand? > > As I was saying in the original email, the job that ianal-maven-plugin does is > to ensure that each artifact we generate contains both LICENSE and NOTICE > files, in the appropriate places; otherwise, fail the build. > > We are not talking about generate / remove / update license headers. > > Regards. > >> - Original Message - >>> From: "Francesco Chicchiriccò" >>> To: "dev" >>> Sent: Friday, October 4, 2019 11:59:40 AM >>> Subject: Re: [DISCUSS] How to replace ianal-maven-plugin? >>> On 04/10/19 09:55, Misagh Moayyed wrote: >>>>> We can only think to replace its features with something else; the job >>>>> that >>>>> ianal-maven-plugin does is to ensure that each artifact we generate >>>>> contains >>>>> both LICENSE and NOTICE files, in the appropriate places; otherwise, fail >>>>> the >>>>> build. >>>>> >>>>> Any idea about how to obtain the same feature with other plugin(s)? >>>> I have used the following in the past: >>>> >>>> - https://github.com/Jasig/maven-notice-plugin (...which I more or less >>>> maintain >>>> with others) >>>> - https://github.com/mycila/license-maven-plugin >>>> >>>> I am not sure if they are really that much better than the current plugin, >>>> but >>>> it's worth trying them out with Syncope. >>> Are you sure that such two plugins do the job that ianal-maven-plugin does? >>> As >>> far as I can see, the former generates NOTICE files, while the latter does >>> more >>> or less the same job that Apache RAT does. > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
Re: [DISCUSS] How to replace ianal-maven-plugin?
I think the license-maven-plugin does have the ability to generate license headers or remove/update them. Is that not the behavior we are looking for, or do I misunderstand? --Misagh - Original Message - > From: "Francesco Chicchiriccò" > To: "dev" > Sent: Friday, October 4, 2019 11:59:40 AM > Subject: Re: [DISCUSS] How to replace ianal-maven-plugin? > On 04/10/19 09:55, Misagh Moayyed wrote: >>> We can only think to replace its features with something else; the job that >>> ianal-maven-plugin does is to ensure that each artifact we generate contains >>> both LICENSE and NOTICE files, in the appropriate places; otherwise, fail >>> the >>> build. >>> >>> Any idea about how to obtain the same feature with other plugin(s)? >> >> I have used the following in the past: >> >> - https://github.com/Jasig/maven-notice-plugin (...which I more or less >> maintain >> with others) >> - https://github.com/mycila/license-maven-plugin >> >> I am not sure if they are really that much better than the current plugin, >> but >> it's worth trying them out with Syncope. > > Are you sure that such two plugins do the job that ianal-maven-plugin does? As > far as I can see, the former generates NOTICE files, while the latter does > more > or less the same job that Apache RAT does. > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
