Shiro กับ SpringSecurity [ปิด]


132

ขณะนี้ฉันได้ประเมินกรอบการรักษาความปลอดภัยที่ใช้ Java ฉันเป็นผู้ใช้ Spring 3.0 ดังนั้นดูเหมือนว่า SpringSecurity จะเป็นตัวเลือกที่เหมาะสม แต่การรักษาความปลอดภัยของ Spring ดูเหมือนจะประสบกับความซับซ้อนมากเกินไปดูเหมือนว่าจะไม่ทำให้การรักษาความปลอดภัยง่ายขึ้นอย่างแน่นอน ชิโระดูเหมือนจะเข้ากันและเข้าใจง่ายกว่ามาก ฉันกำลังมองหารายการข้อดีข้อเสียระหว่างสองกรอบนี้

คำตอบ:


118

ฉันยอมรับเช่นกันว่า Spring Security รู้สึกซับซ้อนเกินไป (สำหรับฉัน) แน่นอนว่าพวกเขาได้ทำสิ่งต่างๆเพื่อลดความซับซ้อนเช่นการสร้างเนมสเปซ XML ที่กำหนดเองเพื่อลดปริมาณการกำหนดค่า XML แต่สำหรับฉันสิ่งเหล่านี้ไม่ได้ช่วยแก้ปัญหาพื้นฐานส่วนตัวของฉันกับ Spring Security: ชื่อและแนวคิดมักจะสับสนโดยทั่วไป ผม. มันยากที่จะ 'รับมัน'

วินาทีที่คุณเริ่มใช้ชิโระคุณก็แค่ 'เข้าใจ' สิ่งที่ยากที่จะเข้าใจในโลกแห่งความปลอดภัยนั้นเข้าใจง่ายกว่ามาก สิ่งที่ยากเหลือทนที่จะใช้ใน JDK (เช่น Ciphers) ถูกทำให้ง่ายขึ้นจนถึงระดับที่ไม่เพียง แต่ทนทาน แต่มักจะเป็นความสุขที่จะใช้

ตัวอย่างเช่นคุณแฮช + เกลือรหัสผ่านและ base64 เข้ารหัสใน Java หรือ Spring Security ได้อย่างไร ไม่ง่ายและใช้งานง่ายเหมือนโซลูชันของ Shiro:

ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();

ไม่จำเป็นต้องใช้ตัวแปลงสัญญาณคอมมอนส์หรือสิ่งอื่นใด แค่โถชิโระ

ตอนนี้เกี่ยวกับสภาพแวดล้อม Spring นักพัฒนา Shiro ส่วนใหญ่ใช้ Spring เป็นสภาพแวดล้อมแอปพลิเคชันหลัก นั่นหมายความว่าการผสานรวม Spring ของ Shiro นั้นยอดเยี่ยมและทุกอย่างทำงานได้ดีเป็นพิเศษ คุณสามารถมั่นใจได้ว่าหากคุณเขียนแอป Spring คุณจะได้รับประสบการณ์ด้านความปลอดภัยที่รอบรู้

ตัวอย่างเช่นพิจารณาตัวอย่างการกำหนดค่า Spring XML ในโพสต์อื่นในเธรดนี้ นี่คือวิธีที่คุณทำ (โดยพื้นฐาน) ในสิ่งเดียวกันใน Shiro:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd>

<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login.jsp"/>
    <property name="successUrl" value="/home.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
        /secure/** = authc
        /** = anon
        </value>
    </property>
</bean>

<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
    <property name="realm" ref="myRealm"/>
</bean>

<bean id="myRealm" class="...">
    ...
</bean>

แม้ว่าจะมีรายละเอียดมากกว่าตัวอย่าง Spring อื่น ๆ เล็กน้อย แต่ก็อ่าน IMO ได้ง่ายกว่า

นอกจากนี้คุณจะพบว่าการใช้คำจำกัดความของห่วงโซ่ตัวกรองของ Shiro อาจเป็นวิธีที่ง่ายที่สุดในการกำหนดเครือข่ายตัวกรองทั่วไปและกฎความปลอดภัยบนเว็บเลยทีเดียว! ดีกว่าการกำหนดใน web.xml

ในที่สุด Shiro ก็มี 'pluggability' ที่ยอดเยี่ยม คุณจะเห็นว่าคุณสามารถกำหนดค่าและ / หรือแทนที่อะไรก็ได้เพราะสถาปัตยกรรม POJO / injection-friendly ของ Shiro Shiro ตั้งค่าเริ่มต้นเกือบทุกอย่างเป็นค่าเริ่มต้นที่ดีและคุณสามารถแทนที่หรือกำหนดค่าเฉพาะสิ่งที่คุณต้องการได้

ในตอนท้ายของวันฉันคิดว่าการเลือกทั้งสองอย่างนี้เกี่ยวข้องกับแบบจำลองทางจิตของคุณมากกว่า - ข้อใดในสองข้อที่เหมาะสมกว่าและใช้งานง่ายสำหรับคุณ สำหรับบางคนจะเป็นชิโระส่วนคนอื่น ๆ จะเป็น Spring Security ชิโระใช้งานได้ดีในสภาพแวดล้อมฤดูใบไม้ผลิดังนั้นฉันจะบอกว่าเลือกตามว่าคุณชอบแบบไหนมากกว่ากันและเหมาะสมกับคุณมากที่สุด

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการรวม Spring ของ Shiro: http://shiro.apache.org/spring.html


ฉันได้อ่านทั้งหมดนี้ก่อนที่จะเริ่มใช้ชิโระ คำอธิบายประกอบของ Shiro ดูเหมือนจะประสบปัญหาบางอย่างในฤดูใบไม้ผลิข้อมูลเกี่ยวกับวิธีแก้ปัญหานั้นยากมากและมีโพสต์ต่างๆใน stackoverflow (1 หรือ 2 โพสต์โดยตัวฉันเอง) ซึ่งส่วนใหญ่ไม่พบคำตอบ ฉันคิดอย่างจริงจังว่าฉันควรจะรักษาความปลอดภัยในฤดูใบไม้ผลิแม้ว่ามันจะมีความซับซ้อน แต่ฉันแน่ใจว่าฉันสามารถมีคนชี้ทางที่ถูกต้องให้ฉันได้
— อาจารย์ดำ

@blacksensei คุณแก้ปัญหาที่คุณพูดถึงหรือไม่? ติดกับ Shiro หรือเปลี่ยนมาใช้ Spring Security?
— Alexander Suraphel

สวัสดี @AlexanderSuraphel ฉันไม่ได้ย้ายไปที่ Spring สำหรับโครงการนั้น เพื่อนร่วมงานกำลังใช้งานอยู่ และฉันวางแผนที่จะทดสอบในโครงการสปริงบูต มันทำงานได้ดีสำหรับฉัน ฉันจะย้ายโครงการอื่น ๆ ทั้งหมด ง่ายๆอย่างนั้น
— อาจารย์ดำ

ตกลงฉันจะลอง Shiro สำหรับโปรเจ็กต์ต่อไป !!
— Eric Wang

32

ฉันไม่มีประสบการณ์ในการใช้ Shiro และฉัน "บางส่วน" เห็นด้วยกับสิ่งที่คุณพูดเกี่ยวกับ Spring Security ก่อนหน้า Spring Security 3.x Spring Security (หรือ Acegi) เจ็บปวดมากในการตั้งค่า การกำหนดค่าตามบทบาทอย่างง่ายจะใช้การกำหนดค่า XML ที่เป็นความลับอย่างน้อย 140 บรรทัด ... ฉันรู้สิ่งนี้เพราะฉันนับบรรทัดด้วยตัวเองจริงๆ เป็นสิ่งที่คุณตั้งค่าครั้งเดียวและคุณอธิษฐานว่ามันจะใช้งานได้ตลอดไปโดยที่คุณไม่ต้องสัมผัสการกำหนดค่าอีกครั้งเพราะคุณมั่นใจได้ว่าคุณลืมความหมายของการกำหนดค่าทั้งหมด :)

ด้วย Spring Security 3.x ได้รับการปรับปรุงอย่างมากเมื่อ แนะนำsecurityเนมสเปซที่ทำให้การกำหนดค่าสั้นลงอย่างมากจาก 140 บรรทัดเหลือ ~ 30 บรรทัด นี่คือตัวอย่างของ Spring Security 3.x ของหนึ่งในโครงการของฉัน: -

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd">

    <security:http auto-config="true">
        <security:form-login login-page="/index.do" authentication-failure-url="/index.do?login_error=1" default-target-url="/index.do"
            always-use-default-target="true" />
        <security:logout logout-success-url="/index.do" />
        <security:intercept-url pattern="/secure/**" access="ROLE_ADMIN,ROLE_USER" />
        <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    </security:http>

    <bean id="customAuthenticationProvider" class="my.project.CustomAuthenticationProviderImpl">
        ...
    </bean>

    <security:authentication-manager>
        <security:authentication-provider ref="customAuthenticationProvider" />
    </security:authentication-manager>

</beans>

ความสวยงามของ Spring Security 3.x นั้นสามารถกำหนดค่าได้อย่างมากซึ่งก่อให้เกิดข้อเสียหลักประการหนึ่ง: ซับซ้อนเกินกว่าจะเข้าใจ เอกสารไม่ใช่เรื่องง่ายที่จะอ่านเพราะฉันคุ้นเคยกับคำศัพท์ Spring Security ที่ใช้เพียงบางส่วน อย่างไรก็ตามมีตัวเลือกให้เลือกหากคุณต้องการสร้างการกำหนดค่าที่กำหนดเองหรือควบคุมความละเอียดที่คุณต้องการให้มีความปลอดภัย หรือคุณสามารถใช้ <30 บรรทัดข้างต้นเพื่อทำการตรวจสอบความปลอดภัยตามบทบาท

สิ่งที่ฉันชอบมากเกี่ยวกับ Spring Security คือเมื่อตั้งค่าการรักษาความปลอดภัยจะรวมเข้ากับโครงการได้อย่างราบรื่น เหมือนกับว่ารหัสโครงการจริงไม่ทราบการมีอยู่ของการรักษาความปลอดภัย ... และนั่นเป็นสิ่งที่ดีเพราะมันช่วยให้ฉันสามารถถอดหรืออัปเกรดองค์ประกอบความปลอดภัยในอนาคตได้อย่างง่ายดาย (เช่นเปลี่ยนการตรวจสอบความถูกต้องของฐานข้อมูลเป็น LDAP / CAS รับรองความถูกต้อง)


คุณต้องการที่จะพูดบางอย่างเกี่ยวกับเวลาที่ดีที่จะย้ายจากการรักษาความปลอดภัยตามคอนเทนเนอร์ไปเป็นทางเลือกอื่นเช่นชิโระหรืออื่น ๆ ดูคำถามเพิ่มเติมได้ที่นี่stackoverflow.com/questions/7782720/…
— Rajat Gupta

10
ฉันได้ลองใช้ทั้ง shiro และ spring security และโดยส่วนตัวแล้วฉันรู้สึกว่า shiro นั้นค่อนข้างเข้าใจได้ง่ายโดยที่การรักษาความปลอดภัยในฤดูใบไม้ผลิให้ความรู้สึกซับซ้อน ฉันยังไม่ทราบวิธีตั้งค่าสิทธิ์ที่ฉันสามารถกำหนดให้กับบทบาท / กลุ่ม / ผู้ใช้ในการรักษาความปลอดภัยในฤดูใบไม้ผลิ - (ฉันคิดว่า ACL อาจเป็นทางออก) ด้วยชิโระมันค่อนข้างง่าย ฉันไม่ได้เชี่ยวชาญด้านความปลอดภัยในฤดูใบไม้ผลิหรือชิโระมันเป็นเพียงประสบการณ์ส่วนตัวของฉันในฐานะผู้ใช้ทั้งสองอย่าง
— Sudhir N

@sudhir คุณพบปัญหาคอขวดใน configurablity ของ Shiro หรือไม่?
— Alexander Suraphel

มันใช้ได้กับทุกกรณีผู้ใช้ของเราฉันคิดว่าเป็นไปได้ที่จะปรับแต่งให้เหมาะกับสถานการณ์ส่วนใหญ่ เคสของคุณเป็นแบบไหน?
— Sudhir N

21

ฉันใช้ Spring Security (เวอร์ชัน 3.1) มาสองสามเดือนแล้วและค่อนข้างพอใจกับมัน มันทรงพลังมากและมีคุณสมบัติที่ดีมากโดยเฉพาะหลังจากใช้งานทุกอย่างด้วยมือเหมือนที่เคยทำมาก่อน! มันเหมือนกับว่าฉันอ่านที่ไหนสักแห่งเรียงลำดับของสิ่งที่คุณตั้งไว้เมื่อใกล้จุดเริ่มต้นของการพัฒนาแอพแล้วอธิษฐานให้แอพทำงานต่อไปจนจบเพราะถ้าคุณต้องไปแก้ไขคุณจะ อาจจะลืมสิ่งส่วนใหญ่ที่คุณต้องกำหนดพารามิเตอร์

แต่แล้วโครงการใหม่ก็มาพร้อมกับข้อกำหนดด้านความปลอดภัยที่ซับซ้อนมากขึ้น ในระยะสั้นเราต้องใช้ SSO ที่กำหนดเองบางประเภทระหว่างเว็บแอปที่เกี่ยวข้องสองรายการ

ฉันรู้ดีว่าฉันต้องการบรรลุอะไรในแง่ของตรรกะ HTTP, คุกกี้, รหัสเซสชันและสิ่งต่างๆและสิ่งที่ควรเกิดขึ้นตามลำดับ แต่ฉันใช้เวลาส่วนที่ดีกว่าในหนึ่งวันในการต่อสู้กับ Spring Security APIs และยังไม่สามารถเข้าใจ ไม่ว่าคลาสหรืออินเทอร์เฟซใดที่ฉันจะใช้หรือลบล้างและวิธีการเสียบเข้ากับบริบท API ทั้งหมดให้ความรู้สึกซับซ้อนและค่อนข้างลึกลับในบางครั้ง และแม้ว่าเอกสารจะค่อนข้างดีสำหรับกรณีการใช้งานทั่วไปและแม้แต่การปรับแต่งบางอย่าง แต่ก็ไม่ได้ลึกพอที่จะครอบคลุมความต้องการของฉัน

หลังจากอ่านคำตอบที่นี่และที่อื่น ๆ บนเว็บแล้วฉันรู้สึกว่าชิโระเข้าใจและปรับแต่งตามความต้องการของฉันได้ง่ายขึ้น ผมก็เลยลองดู

และฉันดีใจที่ได้ทำเพราะหลังจากทำงานกับมันมาทั้งวันฉันสามารถเรียนรู้เกี่ยวกับ API ได้มากพอไม่เพียง แต่จะตั้งค่าระบบการตรวจสอบสิทธิ์และการให้สิทธิ์ขั้นพื้นฐานในเว็บแอป Spring ของฉันโดยไม่มีปัญหา แต่ยังสามารถใช้พฤติกรรม SSO ที่กำหนดเองได้อีกด้วย กำลังมองหา. ฉันต้องขยายคลาส 2 หรือ 3 คลาสเท่านั้นและสิ่งทั้งหมดใช้การกำหนดค่า XML ประมาณ 25 บรรทัดในบริบทฤดูใบไม้ผลิของฉัน

ดังนั้นในการสรุปความง่ายในการใช้งานและแง่มุมการเรียนรู้ Shiro เป็นที่ชื่นชอบมากและฉันคิดว่าฉันอาจจะไปกับมันในอนาคตเว้นแต่ฉันจะพบกับคุณสมบัติบางอย่างที่ขาดหรือมีปัญหาอื่น ๆ (ซึ่งฉันไม่ได้ทำ จนถึงขณะนี้)

TL; DR: ทั้งสองมีพลัง แต่ชิโระเรียนรู้ได้ง่ายกว่ามาก


ปิแอร์ขอบคุณสำหรับข้อมูล ฉันต้องการ sso ด้วย ฉันไม่คิดว่าคุณจะแสดงตัวอย่างของคลาสที่คุณต้องเปิดเผย
— KingAndrew

@KingAndrew: พูดไม่กี่คำสิ่งที่ฉันทำคือใช้ AuthorizingRealm, AuthenticationToken และ AuthenticationFilter ของตัวเอง และตัวกรองและท่อประปาที่จำเป็นทั้งหมด แต่สิ่งที่ฉันทำไม่ใช่ sso "ปกติ" มันขึ้นอยู่กับโทเค็นที่เก็บไว้ในฐานข้อมูลที่ใช้ร่วมกันระหว่าง 2 แอพ ดังนั้นฉันไม่ได้ใช้เซิร์ฟเวอร์ SSO แยกต่างหาก
— Pierre Henry
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.