Skip to main content
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
DEBAL_DAS
DEBAL_DASAccepted solution
New Member
September 28, 2022
  • rep:authorizableId
    • The id that you would lookup the user in the authorisation api
  • rep:principalName
    • The principal name
    • Should be the same as the authorizableId

 

Please refer https://blogs.taylor-made-software.co.uk/aem/101/build/apps/users.html and Solved: Re: com.adobe.granite.security.user.UserProperties... - Adobe Experience League Community - 447117

Debal Das, Senior AEM Consultant
View in thread

3 replies

arunpatidar
Community Advisor
arunpatidarCommunity Advisor
Community Advisor
September 28, 2022
Handling of the Authorizable ID
  • As of Oak 1.0 the node type definition of rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group.
  • This property is protected and system maintained and cannot be changed after creation through user management API calls.
  • The default implementation comes with a dedicated property index for rep:authorizableId which asserts the uniqueness of that ID.
  • For backwards compatibility with Jackrabbit 2.x the ID specified during creation is also reflected in the jcr:uuid (protected and mandatory), which is used for the lookup.
  • Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the rep:authorizableId property is missing.
  • The name of the authorizable node is generated based on a configurable implementation of the AuthorizableNodeName interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name.
- rep:principalName  (STRING) protected mandatory
- rep:authorizableId (STRING) protected /* @since oak 1.0 */

 

Translate
Arun Patidar
    DEBAL_DAS
    DEBAL_DASAccepted solution
    New Member
    September 28, 2022
    • rep:authorizableId
      • The id that you would lookup the user in the authorisation api
    • rep:principalName
      • The principal name
      • Should be the same as the authorizableId

     

    Please refer https://blogs.taylor-made-software.co.uk/aem/101/build/apps/users.html and Solved: Re: com.adobe.granite.security.user.UserProperties... - Adobe Experience League Community - 447117

    Translate
    Debal Das, Senior AEM Consultant
      Rohan_Garg
      Community Advisor
      Rohan_GargCommunity Advisor
      Community Advisor
      July 17, 2023

      Please note the difference between Authorizable and Principal:
      An Authorizable is repository object that is neither associated with nor depending from a particular Session and thus independent of the login mechanisms creating Sessions.

      On the other hand Principals are representations of user identities. In other words: each Principal within the set associated with the Session's Subject upon login represents an identity for that user. An the set of Principals may differ between different login mechanisms.

      Consequently an one-to-many relationship exists between Authorizable and Principal (see also getPrincipal().

       

      Source -

      https://developer.adobe.com/experience-manager/reference-materials/6-4/javadoc/org/apache/jackrabbit/api/security/user/Authorizable.html

      Translate
      Rohan Garg
        Terms & ConditionsAccessibility statement

        Loading footer...