Replies: 13 comments 3 replies
-
|
Answer Template for Copy and Paste
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
California Academy of Sciences
No
No
No
No
No
AD, optionally yes.
We can use AD, above, yes. We access this via SSSD on linux machines, and that works well. |
Beta Was this translation helpful? Give feedback.
-
The University of Michigan
Yes, Shibboleth
Yes, inCommon
Possibly.
No
Yes, Shibboleth/SAML
Yes, I believe we have used this in one application because we were forced to for the service we wanted to integrate. We use Shibboleth mostly though.
Yes, LDAP
Yes, we do support SSO, however our Specify users jump between S6 and S7 a lot due to S7 not being able to do everything S6 can do, so currently they use the same account ID and password setup in S6 to access S7.
I do not know. |
Beta Was this translation helpful? Give feedback.
-
Fedor Alexander Steeman / Natural History Museum of Denmark - University of Copenhagen
Yes, but we don't know the details.
Neither.
Yes, as long as it's not enforced. Not of all our end users are registered at our university as staff members and will not have a CI logon. It would be welcomed as an addition, but it should be possible to be turned off for individual installations.
No.
Not as far as I know.
Perhaps via ORCID but uncertain.
Maybe AD / LDAP is involved somewhere in the chain of a rather complex system, but I'm uncertain how.
Yes, this is how our setup works currently. Just username/password combo created in Sp6 on the fly.
No enforcing of SSO logon or ability to turn this off per installation. |
Beta Was this translation helpful? Give feedback.
-
|
In Specify 7, to what extent is SSO authentication necessary?
Have the security implications for SSO integration been assessed?
It is my understanding that a few institutions have mandated SSO integration. However, a strict SSO policy for every web based system is bound to run into extensive problems across the institution. It's also telling that most of the responses are inclusive. A general "I have no idea what we use". If Specify were to integrate SSO, this lack of understanding would need to be bridged on a case by case basis, which is a costly task.
For an organization, SSO allows seamless integration with various intranet applications. Specify isn't going to integrate with internal administrative tools such as a Human Resources dashboard. This would imply a minimal benefit at the organization level.
Companies like Google and Facebook that provide SSO have a financial goal. They track your activity to sell more adds. Given the 14 000 credentials we all keep, social login mechanisms have popped up everywhere. That doesn't mean they are a good thing, nor should they be adopted by small organizations.
The above points make it hard to justify SSO integration. Aside from the few mandates, the only tangible benefits that I am aware of is an easy way to login. Thats not exactly a use case the warrants the allocation of resources from a very limited supply.
I'm not privy to every use case or scenario, but these are important points to rectify, especially given the current priorities and features behind schedule.
- Ben
Ben Norton
Head of Technology
Collections Data Curator
Collections Manager, Mineralogy
Research & Collections
North Carolina Museum of Natural Sciences
https://naturalsciences.org/staff/ben-norton
***@***.******@***.***>
919.707.9947
[Sent from Mobile Device]
…________________________________
From: Fedor Alexander Steeman ***@***.***>
Sent: Monday, January 10, 2022 6:28 AM
To: specify/specify7
Cc: Norton, Ben; Comment
Subject: [External] Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
1. Name/Institution:
Fedor Alexander Steeman / Natural History Museum of Denmark - University of Copenhagen
1. SSO?
Yes, but we don't know the details.
1. InCommon or EduGain?
Neither.
1. CILogon?
Yes, as long as it's not enforced. Not of all our end users are registered at our university as staff members and will not have a CI logon. It would be welcomed as an addition, but it should be possible to be turned off for individual installations.
1. 3rd Party IdP?
No.
1. Shibboleth or other SAML?
Not as far as I know.
1. OpenID Connect?
Perhaps via ORCID but uncertain.
1. LDAP or AD:
Maybe AD / LDAP is involved somewhere in the chain of a rather complex system, but I'm uncertain how.
1. No campus SSO Services:
Yes, this is how our setup works currently. Just username/password combo created on the fly.
1. Other Authentication Requirements?
No enforcing of SSO logon or ability to turn this off per installation.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/specify/specify7/discussions/1133*discussioncomment-1939545__;Iw!!HYmSToo!LGBcG2y4tD53jHG2qrWGA7gDiDzX5TQolK0LpYXNcDOZEC7g9TG8Rsj2SgnJitxw2SuRJVk$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABX55QE46DBXNOIX7GTBQW3UVK7F3ANCNFSM5KQTNYUQ__;!!HYmSToo!LGBcG2y4tD53jHG2qrWGA7gDiDzX5TQolK0LpYXNcDOZEC7g9TG8Rsj2SgnJitxwF4Uqfxc$>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Ben, thanks for contributing these points. I would like to highlight for everyone the difference between authentication (AuthN) and authorization (AuthZ). Authentication is just handling of the username and password, which is where SSO comes into play. Authorization is post authentication and is the mapping of security access to an authenticated user. It is possible to implement SSO for authentication only on web apps by simply configuring the web server to require SSO for the app. This is independent of the application and the IdP/Sp infrastructure will already be present in those institutions that support SSO. The advantage of this is that the application, i.e. Specify. 7, is now behind the institutional safeguards mandated in the SSO. At UF, and many other places, this would place the application behind a Two or Multifactor Authentication barrier, dramatically increasing its security. At UF, we use DUO with our SSO, which is quite common in higher ed. In fact, SSO configuration for authentication is already available with the current implementation of Specify 7, as it is a server side configuration and app independent. This is good news, as SSO for web apps is commonly mandated by institutional Risk Management offices. It is here at UF. The sticky wicket is really the authorization side of the house where the authenticated SSO user is passed to the application and the security principles are mapped accordingly. This is where the most flexibility is needed, as the the directory structure and security groups will vary widely from institution to institution. The good news is that accommodation is a low technical lift, as LDAP is nearly ubiquitous. It could be as simple as configuring an LDAP query for each security role in Specify 7 one wishes to map. There is no programming lift to implement SSO for authentication, and the programming lift to implement SSO for authorization is not necessarily trivial, but certainly not a heavy lift. The real challenge is divining the best model for permission management and granularity within Specify 7, which is independent of mapping user ids to principals. Best, Warren Brown |
Beta Was this translation helpful? Give feedback.
-
|
This is an absolutely fantastic write-up. Thank you Warren for doing this! |
Beta Was this translation helpful? Give feedback.
-
|
Name/Institution: CSIRO SSO? YES Microsoft MFA, Kerberos - Apache Krb5, NTML, SAML InCommon or EduGain? Not at the moment but, there are discussions and requests to provide support for inCommon logins on our some of our research apps._ CILogon? NO 3rd Party IdP? YES MICROSOFT MFA Shibboleth or other SAML? YES and Shibboleth/SAML IdP OpenID Connect? LDAP or AD: YES No campus SSO Services: Other Authentication Requirements? |
Beta Was this translation helpful? Give feedback.
-
|
Name/Institution Does your institution, campus, or organization use a single sign-on (SSO) authentication system for validating user credentials? If yes, please briefly identify the major components of your SSO system. Is your institution a member of the inCommon Federation? (See: https://incommon.org/community-organizations/), or other identity provider federation registered with eduGAIN? (See: https://technical.edugain.org/status) Would authentication through CILogon be a viable mechanism for gaining access to Specify 7 at your institution? Is your institutional primary authentication system for research software users hosted in the cloud by a third-party Identity Provider? E.g. Google, Okta, Amazon, Microsoft, GitHub. Is your campus/institution operating a Shibboleth or other SAML-based Identity Provider (IdP)? Does your institution authenticate users using OpenID Connect? Does your institution use LDAP or Active Directory for granting user authorizations? Are authorizations resolved to the level of permissions granted to user groups defined within applications like Specify? Does your institution not support SSO services, thus requiring, while using a local installation of Specify 7, the use local user logins with Specify account IDs and passwords stored in Specify 7 database? Have any other requirements that might apply to authentication for running the Specify 7 platform with an SSO service at your institution? Thanks! Warren Brown |
Beta Was this translation helpful? Give feedback.
-
|
If I could add an applause meme, it would go here.
Thanks Warren. Great explanation.
From: Warren H Brown ***@***.***>
Sent: Friday, January 14, 2022 8:42 AM
To: specify/specify7 ***@***.***>
Cc: Norton, Ben ***@***.***>; Comment ***@***.***>
Subject: [External] Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
Hi Ben, thanks for contributing these points. I would like to highlight for everyone the difference between authentication (AuthN) and authorization (AuthZ). Authentication is just handling of the username and password, which is where SSO comes into play. Authorization is post authentication and is the mapping of security access to an authenticated user. It is possible to implement SSO for authentication only on web apps by simply configuring the web server to require SSO for the app. This is independent of the application and the IdP/Sp infrastructure will already be present in those institutions that support SSO. The advantage of this is that the application, i.e. Specify. 7, is now behind the institutional safeguards mandated in the SSO. At UF, and many other places, this would place the application behind a Two or Multifactor Authentication barrier, dramatically increasing its security. At UF, we use DUO with our SSO, which is quite common in higher ed. In fact, SSO configuration for authentication is already available with the current implementation of Specify 7, as it is a server side configuration and app independent. This is good news, as SSO for web apps is commonly mandated by institutional Risk Management offices. It is here at UF.
The sticky wicket is really the authorization side of the house where the authenticated SSO user is passed to the application and the security principles are mapped accordingly. This is where the most flexibility is needed, as the the directory structure and security groups will vary widely from institution to institution. The good news is that accommodation is a low technical lift, as LDAP is nearly ubiquitous. It could be as simple as configuring an LDAP query for each security role in Specify 7 one wishes to map.
There is no programming lift to implement SSO for authentication, and the programming lift to implement SSO for authorization is not necessarily trivial, but certainly not a heavy lift. The real challenge is divining the best model for permission management and granularity within Specify 7, which is independent of mapping user ids to principals.
Best,
Warren
Warren Brown
IT Director, Office of Museum Technology
Florida Museum of Natural History
1659 Museum Rd
Gainesville, FL 32611 | (352) 273-1911
***@***.******@***.***>
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/specify/specify7/discussions/1133*discussioncomment-1969589__;Iw!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hXrBC_W0$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABX55QHUEGHOXG4EDOC2OQ3UWARY5ANCNFSM5KQTNYUQ__;!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hK8Wu5gI$>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Again great explanation, but are you implying that the current question regarding SSO is misplaced? If LDAP takes care of SSO integration, leaving just the application permissions, then should the question be directed toward the latter?
Ben Norton
Head of Technology
Collections Data Curator
Collections Manager, Mineralogy
Research & Collections
North Carolina Museum of Natural Sciences
https://naturalsciences.org/staff/ben-norton
***@***.******@***.***>
919.707.9947
[Sent from Mobile Device]
…________________________________
From: Warren H Brown ***@***.***>
Sent: Friday, January 14, 2022 8:41 AM
To: specify/specify7
Cc: Norton, Ben; Comment
Subject: [External] Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
Hi Ben, thanks for contributing these points. I would like to highlight for everyone the difference between authentication (AuthN) and authorization (AuthZ). Authentication is just handling of the username and password, which is where SSO comes into play. Authorization is post authentication and is the mapping of security access to an authenticated user. It is possible to implement SSO for authentication only on web apps by simply configuring the web server to require SSO for the app. This is independent of the application and the IdP/Sp infrastructure will already be present in those institutions that support SSO. The advantage of this is that the application, i.e. Specify. 7, is now behind the institutional safeguards mandated in the SSO. At UF, and many other places, this would place the application behind a Two or Multifactor Authentication barrier, dramatically increasing its security. At UF, we use DUO with our SSO, which is quite common in higher ed. In fact, SSO configuration for authentication is already available with the current implementation of Specify 7, as it is a server side configuration and app independent. This is good news, as SSO for web apps is commonly mandated by institutional Risk Management offices. It is here at UF.
The sticky wicket is really the authorization side of the house where the authenticated SSO user is passed to the application and the security principles are mapped accordingly. This is where the most flexibility is needed, as the the directory structure and security groups will vary widely from institution to institution. The good news is that accommodation is a low technical lift, as LDAP is nearly ubiquitous. It could be as simple as configuring an LDAP query for each security role in Specify 7 one wishes to map.
There is no programming lift to implement SSO for authentication, and the programming lift to implement SSO for authorization is not necessarily trivial, but certainly not a heavy lift. The real challenge is divining the best model for permission management and granularity within Specify 7, which is independent of mapping user ids to principals.
Best,
Warren
Warren Brown
IT Director, Office of Museum Technology
Florida Museum of Natural History
1659 Museum Rd
Gainesville, FL 32611 | (352) 273-1911
***@***.******@***.***>
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/specify/specify7/discussions/1133*discussioncomment-1969589__;Iw!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hXrBC_W0$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABX55QHUEGHOXG4EDOC2OQ3UWARY5ANCNFSM5KQTNYUQ__;!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hK8Wu5gI$>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Also, does the same logic apply for istitutions that opt not to self-host and instead take advantage of cloud hosting for Specify 7? If the application is not internally hosted, then the internal risk are negated rendering the security advantages irrelevant, correct? If you have a sophisticated and well staffed security apparatus, then the system you describe makes sense. Otherwise, I not convinced that it does.
Ben Norton
Head of Technology
Collections Data Curator
Collections Manager, Mineralogy
Research & Collections
North Carolina Museum of Natural Sciences
https://naturalsciences.org/staff/ben-norton
***@***.******@***.***>
919.707.9947
[Sent from Mobile Device]
…________________________________
From: Warren H Brown ***@***.***>
Sent: Friday, January 14, 2022 8:41 AM
To: specify/specify7
Cc: Norton, Ben; Comment
Subject: [External] Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
Hi Ben, thanks for contributing these points. I would like to highlight for everyone the difference between authentication (AuthN) and authorization (AuthZ). Authentication is just handling of the username and password, which is where SSO comes into play. Authorization is post authentication and is the mapping of security access to an authenticated user. It is possible to implement SSO for authentication only on web apps by simply configuring the web server to require SSO for the app. This is independent of the application and the IdP/Sp infrastructure will already be present in those institutions that support SSO. The advantage of this is that the application, i.e. Specify. 7, is now behind the institutional safeguards mandated in the SSO. At UF, and many other places, this would place the application behind a Two or Multifactor Authentication barrier, dramatically increasing its security. At UF, we use DUO with our SSO, which is quite common in higher ed. In fact, SSO configuration for authentication is already available with the current implementation of Specify 7, as it is a server side configuration and app independent. This is good news, as SSO for web apps is commonly mandated by institutional Risk Management offices. It is here at UF.
The sticky wicket is really the authorization side of the house where the authenticated SSO user is passed to the application and the security principles are mapped accordingly. This is where the most flexibility is needed, as the the directory structure and security groups will vary widely from institution to institution. The good news is that accommodation is a low technical lift, as LDAP is nearly ubiquitous. It could be as simple as configuring an LDAP query for each security role in Specify 7 one wishes to map.
There is no programming lift to implement SSO for authentication, and the programming lift to implement SSO for authorization is not necessarily trivial, but certainly not a heavy lift. The real challenge is divining the best model for permission management and granularity within Specify 7, which is independent of mapping user ids to principals.
Best,
Warren
Warren Brown
IT Director, Office of Museum Technology
Florida Museum of Natural History
1659 Museum Rd
Gainesville, FL 32611 | (352) 273-1911
***@***.******@***.***>
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/specify/specify7/discussions/1133*discussioncomment-1969589__;Iw!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hXrBC_W0$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABX55QHUEGHOXG4EDOC2OQ3UWARY5ANCNFSM5KQTNYUQ__;!!HYmSToo!PbxcrdBK4GmT2ubS0LMSJTR4YB1q9QgBXf3Q08fffvWGubvMn_QqjbLCKPgUDf3hK8Wu5gI$>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Name/Institution: Does your institution, campus, or organization use a single sign-on (SSO) authentication system for validating user credentials? If yes, please briefly identify the major components of your SSO system. Is your institution a member of the inCommon Federation? (See: https://incommon.org/community-organizations/), or other identity provider federation registered with eduGAIN? (See: https://technical.edugain.org/status) Would authentication through CILogon be a viable mechanism for gaining access to Specify 7 at your institution? Is your institutional primary authentication system for research software users hosted in the cloud by a third-party Identity Provider? E.g. Google, Okta, Amazon, Microsoft, GitHub. Is your campus/institution operating a Shibboleth or other SAML-based Identity Provider (IdP)? Does your institution authenticate users using OpenID Connect? Does your institution use LDAP or Active Directory for granting user authorizations? Are authorizations resolved to the level of permissions granted to user groups defined within applications like Specify? Does your institution not support SSO services, thus requiring, while using a local installation of Specify 7, the use local user logins with Specify account IDs and passwords stored in Specify 7 database? Have any other requirements that might apply to authentication for running the Specify 7 platform with an SSO service at your institution? |
Beta Was this translation helpful? Give feedback.
-
|
… ________________________________
From: benritchie ***@***.***>
Sent: Wednesday, January 19, 2022 7:17 AM
To: specify/specify7 ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
Hi
I should introduce myself - I've recently joined RBGE to project manage our specify migration, amongst other things. Prior to that, I was a software developer, and Project Manager in the Telecoms sector. - Great to see your digging into auth requirements here :)
Name/Institution:
Ben Ritchie - Royal Botanic Gardens Edinburgh
Does your institution, campus, or organization use a single sign-on (SSO) authentication system for validating user credentials? If yes, please briefly identify the major components of your SSO system.
we are early in the process of centralising logins/authentication. Our intention is to use Microsoft Active Directory. For the foreeable future, we are likely to have a federated AD system, with an on prem. master, sync'd to a AAD cloud copy.
Is your institution a member of the inCommon Federation? (See: https://incommon.org/community-organizations/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fincommon.org%2Fcommunity-organizations%2F&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tzJB7%2BmozcJXrNO6hrITDUKhrwB6LxeLjzv56jmmX3A%3D&reserved=0>), or other identity provider federation registered with eduGAIN? (See: https://technical.edugain.org/status<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechnical.edugain.org%2Fstatus&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QJpGGTConFPHp1HKt%2BV2IUboo%2BUMH0FwE1I2U0s%2B4C4%3D&reserved=0>)
We do not currently use these, and don't have current plans to do so.
Would authentication through CILogon be a viable mechanism for gaining access to Specify 7 at your institution?
No
Is your institutional primary authentication system for research software users hosted in the cloud by a third-party Identity Provider? E.g. Google, Okta, Amazon, Microsoft, GitHub.
see above, we have cloud access to it, yes. connecting specify to either the cloud, or on prem AAD IdP would be feasable
Is your campus/institution operating a Shibboleth or other SAML-based Identity Provider (IdP)?
We use AD, which supports SAML
Does your institution authenticate users using OpenID Connect?
we can do - via AD
Does your institution use LDAP or Active Directory for granting user authorizations? Are authorizations resolved to the level of permissions granted to user groups defined within applications like Specify?
We haven't yet investigated how we'd do this for Specify. for an initial version, just having a single level of users, with the IDP purely providing Authentication would be a great step forwards. - Fine grained Authorization control isn't a priority for us currently
Does your institution not support SSO services, thus requiring, while using a local installation of Specify 7, the use local user logins with Specify account IDs and passwords stored in Specify 7 database?
We would like to support SSO with Specify, and would adopt it if available
Have any other requirements that might apply to authentication for running the Specify 7 platform with an SSO service at your institution?
We use both specify 6 and 7. Would be good to ensure whatever you do here is applied consistently to both
—
Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspecify%2Fspecify7%2Fdiscussions%2F1133%23discussioncomment-1997693&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eVKeFg9u3FTe2KQJTWkF%2BrcBOh%2FXgdmHe3CooJYyGfk%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC7TVTWRY3SLJEXZWUTLLIDUW22WZANCNFSM5KQTNYUQ&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wYGuL8dT%2BCKHT0xHS9ifqM68OJHXjO5aE09jRI4i5iM%3D&reserved=0>.
Triage notifications on the go with GitHub Mobile for iOS<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VlZPfHd5AHzD6N5qJ9kLEy5wJ4JHBs9UE3tFaXzKqmI%3D&reserved=0> or Android<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2HixcWZDt7rvegpvjTjZKI87hg5DRiUEM5q7nNH0Cnc%3D&reserved=0>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
… ________________________________
From: benritchie ***@***.***>
Sent: Wednesday, January 19, 2022 7:17 AM
To: specify/specify7 ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [specify/specify7] Specify 7 Authentication Survey -- SCC member ideas and input requested for Specify 7 SSO Options (Discussion #1133)
Hi
I should introduce myself - I've recently joined RBGE to project manage our specify migration, amongst other things. Prior to that, I was a software developer, and Project Manager in the Telecoms sector. - Great to see your digging into auth requirements here :)
Name/Institution:
Ben Ritchie - Royal Botanic Gardens Edinburgh
Does your institution, campus, or organization use a single sign-on (SSO) authentication system for validating user credentials? If yes, please briefly identify the major components of your SSO system.
we are early in the process of centralising logins/authentication. Our intention is to use Microsoft Active Directory. For the foreeable future, we are likely to have a federated AD system, with an on prem. master, sync'd to a AAD cloud copy.
Is your institution a member of the inCommon Federation? (See: https://incommon.org/community-organizations/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fincommon.org%2Fcommunity-organizations%2F&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tzJB7%2BmozcJXrNO6hrITDUKhrwB6LxeLjzv56jmmX3A%3D&reserved=0>), or other identity provider federation registered with eduGAIN? (See: https://technical.edugain.org/status<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechnical.edugain.org%2Fstatus&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QJpGGTConFPHp1HKt%2BV2IUboo%2BUMH0FwE1I2U0s%2B4C4%3D&reserved=0>)
We do not currently use these, and don't have current plans to do so.
Would authentication through CILogon be a viable mechanism for gaining access to Specify 7 at your institution?
No
Is your institutional primary authentication system for research software users hosted in the cloud by a third-party Identity Provider? E.g. Google, Okta, Amazon, Microsoft, GitHub.
see above, we have cloud access to it, yes. connecting specify to either the cloud, or on prem AAD IdP would be feasable
Is your campus/institution operating a Shibboleth or other SAML-based Identity Provider (IdP)?
We use AD, which supports SAML
Does your institution authenticate users using OpenID Connect?
we can do - via AD
Does your institution use LDAP or Active Directory for granting user authorizations? Are authorizations resolved to the level of permissions granted to user groups defined within applications like Specify?
We haven't yet investigated how we'd do this for Specify. for an initial version, just having a single level of users, with the IDP purely providing Authentication would be a great step forwards. - Fine grained Authorization control isn't a priority for us currently
Does your institution not support SSO services, thus requiring, while using a local installation of Specify 7, the use local user logins with Specify account IDs and passwords stored in Specify 7 database?
We would like to support SSO with Specify, and would adopt it if available
Have any other requirements that might apply to authentication for running the Specify 7 platform with an SSO service at your institution?
We use both specify 6 and 7. Would be good to ensure whatever you do here is applied consistently to both
—
Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspecify%2Fspecify7%2Fdiscussions%2F1133%23discussioncomment-1997693&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eVKeFg9u3FTe2KQJTWkF%2BrcBOh%2FXgdmHe3CooJYyGfk%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC7TVTWRY3SLJEXZWUTLLIDUW22WZANCNFSM5KQTNYUQ&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wYGuL8dT%2BCKHT0xHS9ifqM68OJHXjO5aE09jRI4i5iM%3D&reserved=0>.
Triage notifications on the go with GitHub Mobile for iOS<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VlZPfHd5AHzD6N5qJ9kLEy5wJ4JHBs9UE3tFaXzKqmI%3D&reserved=0> or Android<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Ctlammer%40ku.edu%7C57bc3047c87d4dd4dd1608d9db4e0d23%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637781950604452014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2HixcWZDt7rvegpvjTjZKI87hg5DRiUEM5q7nNH0Cnc%3D&reserved=0>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Specify 7 Authentication Architecture Survey
20 Dec 2021, Specify Collections Consortium
The Specify Collections Consortium is seeking members’ ideas and input on authentication options for an upcoming release of Specify 7. Authentication is the process of verifying the identity of a user to enable access to an online resource like the Specify 7 software application. Currently Specify 6 and 7 use locally-stored user identity information and encrypted passwords for authentication. Many institutions have a more advanced process of authenticating users--Single-Sign-On (SSO) services use a single, organizational user ID and password to authenticate users for multiple software applications or network resources.
For Specify 7 to take advantage of SSO authentication services, we need to know what (if any) SSO services your organization uses. This information is usually the domain of campus network and security administrators who are responsible for deploying software platforms and maintaining SSO software and the organization’s user directories. That may be you. Or you might have a centralized network/IT support unit who may be able to help with this survey. As Specify member institutions, your effort will be valued, and your responses will inform our development roadmap for Specify 7 integration with organizational SSO services.
(We recently e-mailed a link to a separate Google Forms survey to many Specify users that focused on a new permission system for Specify 7. Permissions and authorizations are distinct from authentication in that they specify allowable functions for users and user groups once a user ID is authenticated.)
Thank you in advance for helping Specify 7 move forward with SSO authentication!
Survey Questions
Name/Institution
Does your institution, campus, or organization use a single sign-on (SSO) authentication system for validating user credentials? If yes, please briefly identify the major components of your SSO system.
Is your institution a member of the inCommon Federation? (See: https://incommon.org/community-organizations/), or other identity provider federation registered with eduGAIN? (See: https://technical.edugain.org/status)
Would authentication through CILogon be a viable mechanism for gaining access to Specify 7 at your institution?
Is your institutional primary authentication system for research software users hosted in the cloud by a third-party Identity Provider? E.g. Google, Okta, Amazon, Microsoft, GitHub.
Is your campus/institution operating a Shibboleth or other SAML-based Identity Provider (IdP)?
Does your institution authenticate users using OpenID Connect?
Does your institution use LDAP or Active Directory for granting user authorizations? Are authorizations resolved to the level of permissions granted to user groups defined within applications like Specify?
Does your institution not support SSO services, thus requiring, while using a local installation of Specify 7, the use local user logins with Specify account IDs and passwords stored in Specify 7 database?
Have any other requirements that might apply to authentication for running the Specify 7 platform with an SSO service at your institution?
Beta Was this translation helpful? Give feedback.
All reactions