Advanced Solr Cluster Security: Authentication and Authorization Framework
Improve user experience with Solr by enhancing security through authentication and authorization plugins. Learn about JWT basics, bundled security plugins, and Solr security prerequisites.
Advanced Solr Cluster Security: Authentication and Authorization Framework
E N D
Presentation Transcript
Not-So-basic Auth Securing your Solr cluster Jason Gerlowski Solr Integration Engineer, Lucidworks Inc @jeg90 #Activate19 #ActivateSearch
Who am I? “Improving the experience users have when picking up Solr for the first time … by adding to SolrJ, the bin/solr scripts, and the documentation” • Jason Gerlowski Email: gerlowskija@apache.org Twitter: @jeg90
What’s “Off the Table”? • “Why” • Third Party Security Tie-ins, External Plugins (Apache Ranger, Apache Sentry) • Writing your own Security Plugin/Working with Plugins in Solr • Kerberos • SSL Configuration • Secure ZK Configuration
Agenda • Authentication and Authorization • Framework details • Plugin Options • Prerequisites • JWT Authentication Plugin • JWT Process and Format • Plugin Configuration • Rule-Based Authorization Plugin • Basic Concepts • Plugin Configuration • Common Mistakes and Misunderstandings
Security Plugin Framework • Supports plugins for authentication, authorization, and audit-logging plugins • Third-party plugins supported. • Simple well-documented API • 4BUNDLED AUTHC PLUGINS • 1BUNDLED AUTHZ PLUGIN • 2AUDIT-LOGGING PLUGINS
{ "authentication":{ "class":"solr.BasicAuthPlugin", "blockUnknown": true, "credentials": {"solr-user":<encoded-creds>", "solr-admin":<encoded-creds>",} }, "authorization":{ "class":"solr.RuleBasedAuthorizationPlugin", "permissions":[ {"name":"security-edit", "role":"admin"}, {"name":"security-read", "role":"admin"} ], "user-role":{ "solr-user":"user", "solr-admin":"admin" } } }
Bundled Security Plugins Authorization • Rule-Based Authorization Authentication • Kerberos • Hadoop Authentication • Basic Authentication • JWT Audit Logging • Solr Log • Multi-Destination
Bundled Security Plugins Authorization • Rule-Based Authorization Authentication • Kerberos • Hadoop Authentication • Basic Authentication • JWT Audit Logging • Solr Log • Multi-Destination
Solr Security Framework Prerequisites • SSL configured? • ZK security enabled? • ZK SSL enabled? ( where available, starting Solr 8.2+) • Disk encryption?
JWT Authentication Token-based model Identity Provider <JWT> User Solr
JWT Authentication Token-based model Identity Provider <JWT> User Solr
JWT Basics What is a JWT anyways? Header{ "alg":"HS256", "typ":"JWT" } Payload { "iat":"14227796", "exp":"14228896", "sub":"username", "iss":"foo.com" ... } Signature <binary>
JWT Basics What is a JWT anyways? base64UrlEncode(header) + ‘.’ + base64UrlEncode(payload) + ‘.’ + base64UrlEncode(signature) eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI curl -k -H “Authorization: Bearer eyJhb..<snip>..SpyHI” “http://host:8983/solr/coll1/select”
Solr JWT Configuration JWK Key {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "jwk": { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "test", "e": "AQAB", "n": "jeyrv..<snip>..MUfqQ" } } }
Solr JWT Configuration (cont’d) JWK URL Configuration {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "jwkUrl": "http://my.key.server.com" } }
Solr JWT Configuration (cont’d) OpenID Connect Configuration {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "wellKnownUrl": "https://foo.openid.com/well-known/open-id-configuration" } }
Solr JWT Configuration (cont’d) Other Configuration Options {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "wellKnownUrl": "https://foo.openid.com/well-known/open-id-configuration", "scope": "solr:read solr:write solr:admin", "requireExp": true, "claimsMatch": { "foo": "A|B", "dept": "IT" }, "algWhitelist": [ "RS256", "RS384", "RS512" ], "jwkCacheDur": 1800 } }
Rule-Based Authorization Core Concepts Permissions - access rules; restrict access to specific “roles” Roles - user-defined grouping for users. Share permissions Users - principal verified by authentication plugin
Rule-Based Authorization Permission Syntax: Predefined • security-read, security-edit, schema-read, schema-edit, config-read, config-edit, core-admin-read, core-admin-edit, collection-admin-read, collection-admin-edit, read, update, all {"name": "read", "role": "dev"}
Rule-Based Authorization Permission Syntax: Custom { "name": "system-export", "collection": "*", "path": "/export", "role": "admin" }
Rule-Based Authorization Security.json Example { "authorization": { "class": "solr.RuleBasedAuthorizationPlugin", "permissions": [ {"name": "foo-access", "collection": "foo", "role": "*"}, {"name": "all", "role": "admin"} ], "user-role": {"admin-user": "admin", "dev-user": "dev"} } }
Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": "dev"}, {"name": "read", "role": "admin"}
Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": "dev"}, {"name": "read", "role": "admin"}
Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": ["dev", "admin"]}
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom.
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. Top - to - Bottom
Rule-Based Authorization Permission Resolution Issue #2 Admin Request? • Check permissions specific to collection and path • Check permissions specific to collection (not path) • Check permissions specific to path (not collection) • Check permissions specific to neither path nor collection No Yes • Check permissions specific path • Check non-path-specific permissions More specific permissions considered first.
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/admin/info
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/admin/info (3)
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/foo/select?q=*:*
Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/foo/select?q=*:* (2)
Rule-Based Authorization Permission Resolution Issue #3 • Permission names matter! {"name": "read", "role": "dev", "method": "GET"}
Rule-Based Authorization Permission Resolution Issue #3 • Predefined permission names are often misleading! Which endpoints does the “read” permission control? • - /solr/collection1/select?q=*:* • - /solr/admin/collections?action=CLUSTERSTATUS • - /solr/admin/collections?action=LIST • - /solr/collection1/export • - /solr/collection1/schema
Rule-Based Authorization Permission Resolution Issue #3 • Predefined permission names are often misleading! Which endpoints does the “read” permission control? • - /solr/collection1/select?q=*:* • - /solr/admin/collections?action=CLUSTERSTATUS • - /solr/admin/collections?action=LIST • - /solr/collection1/export • - /solr/collection1/schema
Rule-Based Authorization Putting it all together • {"name": "all-cols", "role": "A", "collection": "*", "path": "/select"}, • {"name": "custom-schema-read", "role": "A", "path": "/schema"}, • {"name": "read", "role": "B", "collection": "system"}, • {"name": "read-sys", "role": "C", "collection": "system", "params": {"fl": ["secret_field"]}}
Rule-Based Authorization Common Traps • Only the first “matching” permission is considered for a request • Permissions are not (always) processed in the order they appear in security.json • Permission names matter! Override method, params, other attributes. • Predefined permission names are deceptive • Failing open: if no permissions “match”, request is allowed
Rule-Based Authorization Troubleshooting and Tips • Order permissions: most to least specific • End permission list with catch-all permission to prevent “failing open” • Prefix all custom rules to avoid collisions with “predefined” permissions • Raise logging-level for org.apache.solr.security.RuleBasedAuthorizationPlugin (8.3+) • Automate testing of authorization changes
Thank You! http://home.apache.org/~gerlowskija/authcz.pptx