You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@roller.apache.org by "Nick Padilla (Created) (JIRA)" <ji...@apache.org> on 2012/01/25 03:38:40 UTC
[jira] [Created] (ROL-1933) Crowd Login Authentication Roller
Integration
Crowd Login Authentication Roller Integration
---------------------------------------------
Key: ROL-1933
URL: https://issues.apache.org/jira/browse/ROL-1933
Project: Roller
Issue Type: New Feature
Reporter: Nick Padilla
Assignee: Roller Unassigned
Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, security-xml.txt
CROWD:
1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
#required fields
crowd.application.name=roller
crowd.application.password=password
crowd.port=8095
crowd.host=localhost
crowd.context=crowd
#end required fields
#this setting allows the use of https, defaults to false; not present we will use plain socket.
crowd.useSecureConnection=false
crowd.default.timezone=
crowd.default.locale=
You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
# Crowd Auth, need these settings to be enabled
users.sso.enabled=true
users.sso.autoProvision.enabled=true
If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192814#comment-13192814 ]
Nick Padilla commented on ROL-1933:
-----------------------------------
Sorry for the delay on getting this out here, if anyone has any questions please let me know.
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203809#comment-13203809 ]
Nick Padilla commented on ROL-1933:
-----------------------------------
Any idea when this new feature will be added to roller? Just wanted to check in.
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Tiger Gui (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208206#comment-13208206 ]
Tiger Gui commented on ROL-1933:
--------------------------------
If possible, i want to improve and complete mobile template things this summer, and Roller can have available useful mobile device template in 5.1 release
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206570#comment-13206570 ]
Nick Padilla commented on ROL-1933:
-----------------------------------
Thanks for the update! Sounds good, I'll be on the watch for 5.1!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Padilla updated ROL-1933:
------------------------------
Attachment: security-xml.txt
CrowdRollerUserDetails.java
CrowdAuthenticationProvider.java
crowd.properties
BasicUserAutoProvision.txt
Files to enable functionality - remember to add your crowd.properties to the classpath!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Padilla updated ROL-1933:
------------------------------
Attachment: pox-xml.txt
Sorry forgot to add the pom.xml! Again, hope i got the diff files right!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Padilla updated ROL-1933:
------------------------------
Attachment: 2-security-xml.txt
2-roller-properties.txt
2-pom.xml
2-CrowdRollerUserDetails.java
2-CrowdAuthenticationProvider.java
2-BasicUserAutoProvision.txt
Here are the changed files, did a bit of code clean up and initialized the crowdClient in the class constructor - we will now use a cached object instead to save that bit of overhead from creating it every time. Not sure why I didn't do that in the first place. This version should perform better due to this optimization. It is a much cleaner class now. Also, I upgraded the Crowd Client to the latest build. Ran the build and everything passed, of course. I did need to add slf4j because of the upgraded crowd client.
I did run these changes through a test in eclipse and standalone tomcat. All is well!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Dave Johnson (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Johnson resolved ROL-1933.
-------------------------------
Resolution: Fixed
Assignee: David Johnson (was: Roller Unassigned)
Thanks for the patch Nick!
Committed with this SVN rev:
http://svn.apache.org/viewvc?view=revision&revision=1243258
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206468#comment-13206468 ]
Nick Padilla commented on ROL-1933:
-----------------------------------
No problems! Thanks for getting it in so quickly! Which version will this make it in? 5.1.1 or 5.2.0?
Thanks again for everything!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Dave Johnson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206149#comment-13206149 ]
Dave Johnson commented on ROL-1933:
-----------------------------------
This looks pretty good, code-wise, but I would like to see a couple of changes before I introduce it into the Roller code-base:
1) There are a couple of e.printStackTrace() statements that should be replaced with log.debug() or log.error() depending on what is appropriate.
2) Instead of introducing a new properties file, the Crowd properties should be added into roller.properties and the normal Roller properties classes should be used to access them.
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Dave Johnson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206525#comment-13206525 ]
Dave Johnson commented on ROL-1933:
-----------------------------------
Our last release was Roller 5.0 and I suspect that our next release will be 5.1, but I'm not sure we have consensus on release time-frame.
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Dave Johnson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203826#comment-13203826 ]
Dave Johnson commented on ROL-1933:
-----------------------------------
Nick, thanks so much for this work. I plan to take a look at it this week and if it doesn't break things I will add it in.
It appears that you already have an ICLA on file with Apache as a Nicolas Padilla is listed here http://people.apache.org/committer-index.html, can you confirm that's you on the list?
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Padilla updated ROL-1933:
------------------------------
Fix Version/s: 5.1
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: David Johnson
> Labels: authentication, integration
> Fix For: 5.1
>
> Attachments: 2-BasicUserAutoProvision.txt, 2-CrowdAuthenticationProvider.java, 2-CrowdRollerUserDetails.java, 2-pom.xml, 2-roller-properties.txt, 2-security-xml.txt, BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ROL-1933) Crowd Login Authentication Roller
Integration
Posted by "Nick Padilla (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ROL-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206161#comment-13206161 ]
Nick Padilla commented on ROL-1933:
-----------------------------------
Hey Dave!
Sorry, been really busy and haven't had a chance to look at this until today. Yes, that is me in the Unlisted section, always wanted to contribute to the open source community. I will get these changes done and get you some diff files. I would like to take a look at the new changes, but have been super busy the last few months. Once these changes are in and I can have some ammo for upgrading and giving the new changes a try.
Thanks for your time!
> Crowd Login Authentication Roller Integration
> ---------------------------------------------
>
> Key: ROL-1933
> URL: https://issues.apache.org/jira/browse/ROL-1933
> Project: Roller
> Issue Type: New Feature
> Reporter: Nick Padilla
> Assignee: Roller Unassigned
> Labels: authentication, integration
> Attachments: BasicUserAutoProvision.txt, CrowdAuthenticationProvider.java, CrowdRollerUserDetails.java, crowd.properties, pox-xml.txt, security-xml.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> CROWD:
> 1. First off how do we want to handle the demotion or elevation of permissions,groups rather. Say an admin goes to just an editor or an editor goes to admin, currently there will be no change on Roller.
> 2. If user has permissions for the application but is not part of a group, currently it gives editor roles; does that work? If not we need to make a that change.
> 3. Old users can continue to use thier Roller accounts, if the user is a user of the Roller application in Crowd they will authenticate through Crowd. This is as long as the two accounts have the same
> user name. Once authenticated through Crowd, Roller Authentication will not work. So if Crowd goes down and all users are in Crowd then no one will be able to enter the site. Recommendation is to have
> at least one admin user that doesn't have an account in Crowd, this way there will always be a way in.
> 4. If the crowd.properties file is not on the classpath then we never use crowd to authenticate, however if you have users that were authenticated through crowd then they will not be able to login.
> 5. If the user exists in Crowd and has permissions to access Roller and Roller doesn't contain this user account then a new user will be registered automatically; if no groups are setup then the user
> will have editor role, if the user is part of a group that contains the string "admin" or "ADMIN" then that user will be given Admin rights.
> 6. Here is an example crowd.properties file, currently we get the file every time there is a need for it; so that resource will be continually accessed. If this is problem, which I can understand I can
> create a singleton that will hanlde the crowd.properties file and only load it once. This means if any changes are made to the file we have to restart the application.
> #required fields
> crowd.application.name=roller
> crowd.application.password=password
> crowd.port=8095
> crowd.host=localhost
> crowd.context=crowd
> #end required fields
> #this setting allows the use of https, defaults to false; not present we will use plain socket.
> crowd.useSecureConnection=false
> crowd.default.timezone=
> crowd.default.locale=
> You can add this file the same way you add the roller-custom.properties. TimeZone and Locale are not required, but standard format.
> 7. These are the settings that need to be set in the roller-custom.properties to enable the use of Crowd Authentication:
> # Crowd Auth, need these settings to be enabled
> users.sso.enabled=true
> users.sso.autoProvision.enabled=true
> If these are not set Crowd authentication will not work correctly. The AutoProvision is what makes this all work, the users from Crowd and not in Roller will be saved to Rollers db the first time the log in. The reason this is needed
> is so that permissions can be written for Roller. Will still need to add some code to ensure when users get promoted or demoted, those changes make it to the Roller DB.
> Please see attached files as they contain these changes and are in sync with Trunk, as of today. We can extend this functionality but here is working starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira