@albogdano Scoold 1.46.3 is one of the most awaited updates by my team, and it's really great. :thumbsup:
New users are registering with correct email and username from OIDC.
Thanks to config that supports nested fields:
para.security.oauth.parameters.email = "/attributes/Email"
para.security.oauth.parameters.name = "/attributes/DisplayName"
para.security.oauth.parameters.given_name = "/attributes/Imie"
para.security.oauth.parameters.family_name = "/attributes/Nazwisko"But one previously registered with No Name and without email were not updated when sign in on 1.46.3.
Is there any config switch, I could miss, to enable user info updates from OIDC/LDAP?
@albogdano Before support of nested fields user accounts were created with invalid name/email.
Now accounts are created with correct info, but there are two cases:
- Users already created - yes, while they have no posts or customized profile photo/settings they won't notic.
- Existing users info changed (for example get married and chcnged last name, or changed department included in user name), even email could change.
I think it should get updated at Scoold on every sign in, because that user info is owned by OIDC/LDAP and they are the only source of truth about user.
Worth to notice that we have no picture config and it's only customizable by user. It would be evil to reset their image to default on every sign in :smiling_imp:
But when our OIDC let us fill para.security.oauth.parameters.picture = "picture" i would set para.avatar_edits_enabled = false and expect pictures to get updated on sign in just like other data from identity providers.
oa2:sub objects where sub is the sub ID
user for each problematic user
user object -> Scoold profile object
123 then you changed settings and that same user logged in but now with sub 345 and a new user was created so you now have "dead" user objects which need to be deleted
@albogdano AD is a storage for user data, LDAP and OIDC are just different ways to get them.
I could have been wrong about the Scoold users being stored in Mongo (which we use with Para), as You say they are stored in Para. So there's no mongo in process.
OIDC data for para between versions was like:
scoold v. | sub | email | name
1.45.0 | 123 | |
1.46.3 | 123 | user@company.com | Best User (His Department)Also users were able to sign in their No Name accounts using LDAP wchich has a valid user info.
In fact that was our workaround - first login with username/pass trough LDAP to create Scoold account, then use OIDC wchich supports SSO.
In result they got full user data in Scoold, and sign in with OIDC didn't clear user name or email.
While signed in with opposite order, No Name account were created for Scoold and no info were updated after LDAP sign in to the same account.
I'll try to investigate this more after the weekend.
Thank you for your help and have a nice weekend :smiley:
user objects in Para and if they have the correct user data from OIDC
@albogdano At last I had some time to investigate Scoold users.
Looks like there is a problem with profile update.
While user was updated with correct name, profile have old wrong name and new correct originalName.
Method I used to check this.
Search query:para-cli search "creatorid:ID* OR id:ID*"
Where ID is a id field value from result of:para-cli search "type:user AND email:greatuser*"
For users that used ldap and oa2 to login, result is (excluding posts/queries/votes etc.):
sysprop | identifier | id:ldap:...
sysprop | identifier | id:oa2:...
type | profile
type | userOn profile we have name and originalName.profile where identifier for ldap was created before oa2 got valid name and originalName seems ok.profile where identifier for oa2 was created before ldap (and before last update which fixed oa2) got invalid name but originalName seems ok.
Also I have found that long time ago I had different name pattern from ldap like User Name (login) and oa2 is User Name (Office).
My own profile is one of oldest and it has name in old format, but originalName have been updated from oa2.
Last time I used oa2 to signin.
Seems that Scoold uses name field from profile which is not updated with data from identity providers (ldap, oa2).
I didn't write about user object as it contains valid name.
If it would help I can paste this objects.
para.session_timeout = 21600 for 6h session duration (in seconds) and restart. In 6h the auth cookie willexpire but the JWT inside the cookie may still be valid. So make sure you also configure Para to issue JWTs with the same
validity period using
para.jwt_expires_after = 21600 or by updating your Para app object to have a property tokenValiditySec: tokenValiditySec
To save us from running that para-cli command every time, will changing the para config to use the para elasticsearch plugin work to prevent that re-indexing error coming up? and will we have to also spin up an AWS Elasticsearch service to use alongside the plugin?
If you use the ES plugin, you'll definitely need to connect to some Elasticsearch server of your own
Yes, will set up an Elasticsearch server
Regarding the server unhealthy message, it was this
2021-11-02 10:56:11 [WARN ] Server is unhealthy - the search index may be corrupted and may have to be rebuilt.
then after I ran para-cli rebuild-index, the log message was
[INFO ] Server is healthy.
@se-alexnsa I'm pretty sure that your search index is not stored to disk properly. check if the
./datafolder is mounted properly as a volume if using docker.
We're using AWS Fargate.
When running locally using docker, data is at /para/data
I didn't physically mount it, but it was already there when I spun up the container. Do we need to do something differently there?
And how can that be mounted when using Fargate too?
erudikaltd/para-search-elasticsearch image to our already existing dockerfile?
@albogdano Hello! :)
My organization's security team found few bugs in Scoold.
First is with avatar url set by users.
There's no check of what user set, and its served to all other users as avatar.
User can setup malicious link, containing js code which for exapmle could steal auth tokens from cookies.
As example this URL were given:
https://suvroc.github.io/security-demos/XSS/reflectedXSS.html?name=%3Cscript%3Ealert%3C/script%3ERecommendations:
- User input data filtering, for example content-type check.
- Implementing CORS(Cross-Origin Resource Sharing)
- Secure headers
- Implementing CSP(Content Security Policy)
References:
Second is about session.
Cookie scoold-auth with JWT can be stolen and it's valid for 7 days.
Also user session is not closed after logout, with stolen cookie it's possible to get access without login.
Recommendations:
- Proper session closing according to the OWASP: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
- Allowing only one session per user, by closing older sessions while establishing a new one.
References:
I've seen para.jwt_expires_after few posts before.
Correct me if i'm wrong, when set to 300 it will make JWT expire after 5min? It should fix 7 days problem.
But it won't solve existing session after logout.
Both problems were marked as high security risk.
Is there anything that can be done to fix them?
@pikrakpzu Hey, thanks for this! I will work on the code to address these points.
On the first topic: I don't think that's even possible because Scoold has a pretty strict CSP - https://cspvalidator.org/#url=https://live.scoold.com
Security headers are also in place - https://securityheaders.com/?q=https%3A%2F%2Flive.scoold.com&followRedirects=on
There's always room for improvement here and I will soon add filtering of the actual URLs for avatarsOn the second topic: Scoold does not use sessions at all - it uses JWTs instead. It's a similar concept and JWTs can be made to expire after a configurable time period.
para.session_timeoutis the validity period in seconds for the auth cookie itself,para.jwt_expires_afteris the validity period in seconds for the JWT token inside the auth cookie.
Again, here we can tighten security by only allowing one valid JWT per user/browser. It should be pretty straightforward to implement this.