[jira] [Commented] (OAK-4301) Missing protection for system-maintained rep:externalId

2016-08-04 Thread angela (JIRA)

[ 
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407812#comment-15407812
 ] 

angela commented on OAK-4301:
-

Committed revision 1755191.


> Missing protection for system-maintained rep:externalId 
> 
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Critical
>  Labels: security
> Fix For: 1.5.8
>
> Attachments: OAK-4301.patch
>
>
> while working on OAK-4101 i noticed that the current implementation doesn't 
> provide any protection for the system maintained property {{rep:externalId}}, 
> which is intended to be an identifier for a given synchronized user/group 
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API 
> up to now i didn't manage to exploit the missing protection with the current 
> default implementation but i found that minor (legitimate) changes have the 
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation 
> such that the rep:externalId really becomes system-maintained and prevent any 
> unintentional or malicious modification outside of the scope of the 
> sync-operations. furthermore uniqueness of this property should be asserted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OAK-4301) Missing protection for system-maintained rep:externalId

2016-04-27 Thread angela (JIRA)

[ 
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260666#comment-15260666
 ] 

angela commented on OAK-4301:
-

In general defining a dedicated mixin type to identity external user/group 
accounts and mark the required properties (rep:externalId and potentially 
rep:lastSynced) mandatory + protected would look like the most natural and 
desirable option to me.

However, initial work revealed that the nature of current user-sync API (in 
particular {{SyncHandler}}) and the public (exported) default classes (in 
particular {{DefaultSyncContext}}) essential makes an implementation of this 
solution impossible; at least impossible without complete rewrite and 
deprecation of the existing API. 

Consequently, I would opt for an alternative approach that omit a dedicate node 
type (i.e. making the protected nature also obvious and detectable with the JCR 
API) in favor of an Oak-level protection. We may still reconsider heavy rewrite 
of the sync-API on the long run but that's something that IMO would need 
additional justification.

> Missing protection for system-maintained rep:externalId 
> 
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-external, security
>Reporter: angela
>Assignee: angela
>Priority: Critical
>
> while working on OAK-4101 i noticed that the current implementation doesn't 
> provide any protection for the system maintained property {{rep:externalId}}, 
> which is intended to be an identifier for a given synchronized user/group 
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API 
> up to now i didn't manage to exploit the missing protection with the current 
> default implementation but i found that minor (legitimate) changes have the 
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation 
> such that the rep:externalId really becomes system-maintained and prevent any 
> unintentional or malicious modification outside of the scope of the 
> sync-operations. furthermore uniqueness of this property should be asserted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)