Custom profile store for asset share commons

[mrozati]

Contexthub profile store is not appropriate for use on publish The ootb profile store triggers a GET request to /home/users/.../<userId>.infinity.json. This returns not only the user profile, which is needed in asset share, but also all other properties and subnodes of the user, e.g. authentication tokens (.tokens), password hash (@rep:password), samlResponse and rep:policy among others. This is a potential security risk.

On the other hand according to the AEM security checklist requests to *.infinity.json or /home/* should be restricted on publish dispatchers. This makes Asset Share Commons de-facto unsable in real world publish instances.

Custom profile store To solve the problem without braking the ootb contexthub store, the asset share commons should have its own profile store that requests only the public profile of the user /home/users/.../<userId>/profile.infinity.json. Allowing requests to profile subnode does not expose any security risks and is feasible in real world scenarios.

[davidjgonzalez]

@mrozati thanks! I think this is a call made from AEM product code (for the context hub). I searched for "inifinity" in our code base and it doesn't exist - I think the closest we get is a call in our contexthub.js to /libs/granite/security/currentuser.json

Is this call (URL) originating from the ASC code base? If not, im not sure what we can do - if you have suggestions im all ears tho!

[mrozati]

yes, the problematic call comes from "profile" store in AEM product: /libs/granite/contexthub/components/stores/profile/store.profile.js imho we don't need this store at all.

In asset share we already have a call to /libs/granite/security/currentuser.json (contexthub.js#L28) This call actually returns everything we need: authorizableId, fullname and the user path to build up the profile image URL.

So the problem starts in contexthub.js#L34-L42 where we additionally trigger the readiness event on profile store to invoke the initiation of profile component in profile.js#L85

So imo we can eliminate the dependency to the AEM "profile" store, which is obviously considered to be used only on author. Instead of that we just use the data from currentuser.json call and trigger a custom event like PROFILE_READY to init the profile component.

[davidjgonzalez]

@mrozati have you by any chance logged an issue w/ Adobe support about this to validate the security concerns. I agree this seems generally overkill, but the AEM ContentHub profile store is the mechanism for obtaining the user's AEM profile data.

At the same time, I don't think anything under the user's node is secret from them -- they have jcr:read perms on it all, if it is a security risk - it should be protected with real ACLs.

[mrozati]

Actually I didn't file a daycare ticket yet, because I believe the profile contexthub store is designed to be used only on author instance. Denying user to have access to parts of his node would cause bigger problems, e.g. the authentication handler would not be able to read auth tokens and the user cannot login. This is specially the case with OAuth or SSO authentication. So ACL's don't really help in this regard. That's more a problem on the dispatcher side.

In fact the non-public properties are not supposed to be wired over internet, because they can be sniffed by MITM attack. Even in the official AEM security checklist it is recommended that URLs with infinity.json should be blocked in dispatcher.

IMO we have two options:

• we implement a simple profile store that exposes only public profile properties.
• we open a ticket with Adobe support and hope that the make profile store configurable to include or exclude non-public properties. I suppose they see it as an enhancement and schedule for one of future releases.

[davidjgonzalez]

@mrozati contexthub (including the profile store) is intended for use on aem publish. You can see this in the AEM reference implementation in we.retail. aem author doesn’t need/use context hub to personalize its experience since ~all requests go back to AEM anyhow, and personalization can be done server side on request.

I’d log an issue w daycare and see if they can validate this is a security issue/the severity therein. All that data should be the users, so there shouldn’t be a risk of them knowing it? I agree the use of infinity isn’t great, and dumping use data that isn’t really profile data is inelegant, but if adobe supports it, that’s one less thing we don’t have to build/maintain/confuse asc users with.

That said, If we aren’t comfortable w daycares answer, I’m not adverse to building our own into the project.

[shijuc18]

We got in to this problem with our sites. External security vendor recommended to block infinity.json and currentuser.json . Now user profile part completely broken in ASC pages. Can we expect an enhancement soon with a fix ? We are now using 1.9.4 version of ASC

[davidjgonzalez]

@shijuc18 have you neem able to log a Adobe Support ticket? As noted in the above thread, this appears to be spawned from OOTB Context hub.

While i agree .infinity.json is not good usually - this might be an exception if we know that 1) only the browser session associated w/ this user can access it (it's their data) and 2) these node trees are generally small.

It would be good to get Support's opinion on this, before we spend time working around the product, if that makes sense. (and maybe they can even provide an OOTB solution!)