स्प्रिंग सिक्योरिटी में भूमिका और अनुमोदित प्राधिकरण के बीच अंतर

Question

स्प्रिंग सिक्योरिटी में अवधारणाएं और कार्यान्वयन हैं, जैसे इंटरफ़ेस प्राधिकरण प्राप्त करने के लिए प्राधिकरण को नियंत्रित/नियंत्रित करने के लिए।

मुझे लगता है कि अनुमेय संचालन करना चाहते हैं, इस तरह के createSubUsers, या deleteAccounts, जो मैं एक व्यवस्थापक (भूमिका ROLE_ADMIN के साथ) करने की अनुमति होगी के रूप में।

मैं ऑनलाइन देखे जाने वाले ट्यूटोरियल/डेमो के रूप में भ्रमित हो रहा हूं। मैं जो पढ़ता हूं उससे जुड़ने की कोशिश करता हूं, लेकिन मुझे लगता है कि हम दोनों को एक दूसरे के साथ व्यवहार करते हैं।

मुझे hasRoleGrantedAuthority स्ट्रिंग का उपभोग करने वाला लगता है? मैं निश्चित रूप से समझ में गलत कर रहा हूँ। वसंत सुरक्षा में ये अवधारणाएं क्या हैं?

मैं उस भूमिका के लिए अधिकारियों से अलग उपयोगकर्ता की भूमिका कैसे संग्रहीत करूं?

मैं भी org.springframework.security.core.userdetails.UserDetails इंटरफ़ेस जो प्रमाणीकरण प्रदाता संदर्भित डीएओ है, जो एक User (नोट पिछले GrantedAuthority) की खपत में प्रयोग किया जाता है पर देख रहा हूँ:

public User(String username, 
      String password, 
      boolean enabled, 
      boolean accountNonExpired, 
      boolean credentialsNonExpired, 
      boolean accountNonLocked, 
      Collection<? extends GrantedAuthority> authorities) 

या कोई अंतर करने के लिए किसी अन्य तरीके से है अन्य दो? या यह समर्थित नहीं है और हमें अपना खुद का बनाना है?

Answer 1

एक अनुमोदित प्राधिकारी को "अनुमति" या "दाएं" होने के बारे में सोचें। वे "अनुमतियां" (आमतौर पर) तारों के रूप में व्यक्त की जाती हैं (getAuthority() विधि के साथ)। वे तार आपको अनुमतियों की पहचान करने देते हैं और आपके मतदाताओं को यह तय करने देते हैं कि क्या वे किसी चीज़ तक पहुंच प्रदान करते हैं।

आप उपयोगकर्ताओं को सुरक्षा संदर्भ में डालकर विभिन्न अनुदान प्राधिकरण (अनुमतियां) प्रदान कर सकते हैं। आप आमतौर पर ऐसा करते हैं जो आपके स्वयं के UserDetailsService को लागू करके करता है जो उपयोगकर्ता विवरण कार्यान्वयन देता है जो आवश्यक GrantedAuthorities देता है।

भूमिकाएं (जैसा कि वे कई उदाहरणों में उपयोग किए जाते हैं) नामकरण सम्मेलन के साथ केवल "अनुमतियां" हैं जो कहती हैं कि एक भूमिका एक अनुदान प्राधिकृत है जो उपसर्ग ROLE_ से शुरू होती है। और कुछ नहीं है। एक भूमिका सिर्फ एक अनुदान प्राधिकृत है - एक "अनुमति" - एक "दाएं"। आप वसंत सुरक्षा में बहुत से स्थान देखते हैं जहां ROLE_ उपसर्ग के साथ भूमिका विशेष रूप से लागू की जाती है। रोलवॉटर में, जहां ROLE_ उपसर्ग डिफ़ॉल्ट के रूप में उपयोग किया जाता है। यह आपको ROLE_ उपसर्ग के बिना भूमिका नाम प्रदान करने की अनुमति देता है। वसंत सुरक्षा 4 से पहले, "भूमिकाओं" के इस विशेष संचालन का पालन लगातार नहीं किया गया है और अधिकारियों और भूमिकाओं का अक्सर इलाज किया जाता है (जैसा कि आप hasAuthority() विधि SecurityExpressionRoot में विधि के कार्यान्वयन में देख सकते हैं - जो बस hasRole() पर कॉल करता है)। वसंत सुरक्षा 4 के साथ, भूमिकाओं का उपचार अधिक सुसंगत और कोड है जो "भूमिकाएं" (RoleVoter, hasRole अभिव्यक्ति आदि) से संबंधित है। हमेशा आपके लिए ROLE_ उपसर्ग जोड़ता है। तो hasAuthority('ROLE_ADMIN') का अर्थ hasRole('ADMIN') जैसा है क्योंकि ROLE_ उपसर्ग स्वचालित रूप से जोड़ा जाता है। भविष्य की जानकारी के लिए वसंत सुरक्षा 3 से 4 migration guide देखें।

लेकिन फिर भी: एक भूमिका केवल ROLE_ उपसर्ग के साथ एक प्राधिकरण है। तो वसंत सुरक्षा में 3 @PreAuthorize("hasRole('ROLE_XYZ')")@PreAuthorize("hasAuthority('ROLE_XYZ')") जैसा है और वसंत सुरक्षा 4 @PreAuthorize("hasRole('XYZ')") में @PreAuthorize("hasAuthority('ROLE_XYZ')") जैसा ही है।

आपके उपयोग के मामले के बारे में:

उपयोगकर्ता भूमिकाओं और भूमिकाओं कुछ कार्रवाई करने सकते हैं।

आप GrantedAuthorities में Google की भूमिकाओं के लिए समाप्त हो सकते हैं और संचालन एक भूमिका निभा सकते हैं। भूमिकाओं के लिए GrantedAuthorities में उपसर्ग ROLE_ है और संचालन में उपसर्ग OP_ है। आपरेशन के अधिकारियों के लिए एक उदाहरण हो सकता है OP_DELETE_ACCOUNT, OP_CREATE_USER, OP_RUN_BATCH_JOB आदि भूमिकाओं ROLE_ADMIN, ROLE_USER हो सकता है आदि

आप अपने संस्थाओं की तरह GrantedAuthority लागू इस (छद्म कोड) में उदाहरण के लिए होने लग सकती है:

@Entity 
class Role implements GrantedAuthority { 
    @Id 
    private String id; 

    @OneToMany 
    private final List<Operation> allowedOperations = new ArrayList<>(); 

    @Override 
    public String getAuthority() { 
     return id; 
    } 

    public Collection<GrantedAuthority> getAllowedOperations() { 
     return allowedOperations; 
    } 
} 

@Entity 
class User { 
    @Id 
    private String id; 

    @OneToMany 
    private final List<Role> roles = new ArrayList<>(); 

    public Collection<Role> getRoles() { 
     return roles; 
    } 
} 

@Entity 
class Operation implements GrantedAuthority { 
    @Id 
    private String id; 

    @Override 
    public String getAuthority() { 
     return id; 
    } 
} 

आपके डेटाबेस में आपके द्वारा बनाई गई भूमिकाओं और संचालन के आईडी ग्रिटेड प्राधिकरण प्रतिनिधित्व होंगे, उदाहरण के लिए "ROLE_ADMIN", "OP_DELETE_ACCOUNT" इत्यादि। जब कोई उपयोगकर्ता प्रमाणित होता है, तो सुनिश्चित करें कि इसकी सभी भूमिकाओं और संबंधित संचालन की सभी अनुमोदित प्राधिकारी UserDetails.getAuthorities() विधि से वापस आती हैं।

उदाहरण: आईडी ROLE_ADMIN के साथ व्यवस्थापक भूमिका में ऑपरेशन OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB असाइन किया गया है। आईडी ROLE_USER के साथ उपयोगकर्ता भूमिका ऑपरेशन OP_READ_ACCOUNT है।

जिसके परिणामस्वरूप सुरक्षा के संदर्भ में एक व्यवस्थापक लॉग GrantedAuthorities होगा: ROLE_ADMIN, OP_DELETE_ACCOUNT, OP_READ_ACCOUNT, OP_RUN_BATCH_JOB

तो किसी उपयोगकर्ता के लॉग यह है, यह करना होगा: ROLE_USER, OP_READ_ACCOUNT

UserDetailsService सभी भूमिकाओं और उन भूमिकाओं के सभी संचालनों को इकट्ठा करने और उन्हें वापस लौटाए गए उपयोगकर्ता विवरण उदाहरण में विधि प्राप्त प्राधिकरण() द्वारा उपलब्ध कराएंगे।

Answer 2

AFAIK अनुदान प्राधिकरण और भूमिका वसंत सुरक्षा में समान हैं। GrantedAuthority की getAuthority() स्ट्रिंग भूमिका है (डिफ़ॉल्ट कार्यान्वयन के अनुसार SimpleGrantedAuthority)।

अपने मामले के लिए आप श्रेणीबद्ध भूमिकाओं

<bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter"> 
    <constructor-arg ref="roleHierarchy" /> 
</bean> 
<bean id="roleHierarchy" 
     class="org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl"> 
    <property name="hierarchy"> 
     <value> 
      ROLE_ADMIN > ROLE_createSubUsers 
      ROLE_ADMIN > ROLE_deleteAccounts 
      ROLE_USER > ROLE_viewAccounts 
     </value> 
    </property> 
</bean> 

नहीं सटीक सोल आप के लिए देख उपयोग कर सकते हैं, लेकिन हो सकता आशा है कि यह

संपादित मदद करता है: अपनी टिप्पणी

भूमिका का जवाब दें वसंत-सुरक्षा में अनुमति की तरह है। हैरोल के साथ इंटरसेप्ट-यूआरएल का उपयोग करके भूमिका/अनुमति के लिए किस ऑपरेशन की अनुमति है, इसका एक बहुत अच्छा दाग नियंत्रण प्रदान करता है।

जिस तरह से हम अपने आवेदन में हैं, हम प्रत्येक ऑपरेशन (या बाकी यूआरएल) के लिए अनुमति (यानी भूमिका) परिभाषित करते हैं। view_account, delete_account, add_account आदि। फिर हम व्यवस्थापक, guest_user, normal_user जैसे प्रत्येक उपयोगकर्ता के लिए लॉजिकल प्रोफाइल बनाते हैं। प्रोफाइल बस वसंत-सुरक्षा से स्वतंत्र अनुमतियों का तार्किक समूह है। जब कोई नया उपयोगकर्ता जोड़ा जाता है, तो उसे एक प्रोफ़ाइल असाइन की जाती है (सभी अनुमत अनुमतियां होने पर)। अब जब भी उपयोगकर्ता कुछ कार्रवाई करने का प्रयास करता है, तो उस कार्रवाई के लिए अनुमति/भूमिका उपयोगकर्ता द्वारा अधिकृत प्राधिकरणों के खिलाफ की जाती है।

इसके अलावा डिफ़ॉल्ट रोलवॉटर प्रीफिक्स ROLE_ का उपयोग करता है, इसलिए ROLE_ से शुरू होने वाले किसी भी प्राधिकारी को भूमिका के रूप में माना जाता है, आप भूमिका मतदाता में कस्टम रोलफ्रिक्स का उपयोग करके और वसंत सुरक्षा में इसका उपयोग करके इस डिफ़ॉल्ट व्यवहार को बदल सकते हैं।