kiến thức Spring boot security oauth2 keycloak

Keycloak có adapter cho spring security, nó tự động đẩy role của User đc config trên Keycloak vào roles của UserDetail, cho nên chỉ cần xài hasRole từ security configure hoặc annotation hasRole, hasAuthorities là dc
 
Keycloak có adapter cho spring security, nó tự động đẩy role của User đc config trên Keycloak vào roles của UserDetail, cho nên chỉ cần xài hasRole từ security configure hoặc annotation hasRole, hasAuthorities là dc
nếu muốn lấy role của user trong db thì nên làm sao vậy thím, giống như User nó vừa lưu ở keycloak vừa lưu trong db luôn.

Thớt làm ở công ty tên P ha.
 
mấy cái check này đơn giản, tự viết Filter mà authorize thôi chứ dựa vào spring làm gì.
spring làm mới đầu đơn giản nhưng nó khá là độc đoán, gần với vendor lock-in.
sau này nâng cấp, chuyển stack, etc. sẽ rất mệt.
 
mấy cái check này đơn giản, tự viết Filter mà authorize thôi chứ dựa vào spring làm gì.
spring làm mới đầu đơn giản nhưng nó khá là độc đoán, gần với vendor lock-in.
sau này nâng cấp, chuyển stack, etc. sẽ rất mệt.
Tôi cũng toàn viết filter. Không biết dùng spring security này có ưu việt hơn không chứ ngại đổi quá.
 
Đọc post của thím trên SO ko thấy gì sai vì đã có scope phone trả về ở token enpoint rồi, chắc do code cái của framework.
 
nếu muốn lấy role của user trong db thì nên làm sao vậy thím, giống như User nó vừa lưu ở keycloak vừa lưu trong db luôn.

Thớt làm ở công ty tên P ha.
viết thêm filter query user đó trong db của mình thôi, lấy đc roles từ db của mình rồi thì set thêm vào roles trong UserDetail là đc
// trước đây mình làm fsoft, giờ mình làm cty khác rồi :D
 
Tôi cũng toàn viết filter. Không biết dùng spring security này có ưu việt hơn không chứ ngại đổi quá.
spring security thì nó đơn giản, authen author viết vài dòng là xong, tiện lợi cho hệ thống sử dụng role cứng hoặc role tĩnh, nếu role động, có thể thay đổi ở runtime thì dĩ nhiên viết filter có lợi hơn nhiều, nói chung đã xài framework thì ai cũng muốn tiện, mà tiện thì kiểu gì cũng có bất lợi nào đó, framework gì cũng thế thôi :D
 
Keycloak có adapter cho spring security, nó tự động đẩy role của User đc config trên Keycloak vào roles của UserDetail, cho nên chỉ cần xài hasRole từ security configure hoặc annotation hasRole, hasAuthorities là dc
thường thi check theo role thi những hệ thống front end (js) backend mono mới check kiểu vậy. hệ thống microservice hay check theo kiểu mỗi url là 1 scope ấy ạ. nên e đang muốn custom chỗ này để check theo scope chứ k dùng role. vì xác thực dạng client_credentials nên cũng k tạo user luôn
 
AI phân biệt rạch ròi 2 t/h này giúp e đc ko ạ
@PreAuthorize("#oauth2.hasScope('phone')")
@PreAuthorize("hasAnyAuthority('SCOPE_phone')")
và cách bỏ prefix SCOPE_ là gì ạ ? e thấy chỉ có bỏ ROLE_ chứ k thấy bỏ SCOPE_
 
spring security thì nó đơn giản, authen author viết vài dòng là xong, tiện lợi cho hệ thống sử dụng role cứng hoặc role tĩnh, nếu role động, có thể thay đổi ở runtime thì dĩ nhiên viết filter có lợi hơn nhiều, nói chung đã xài framework thì ai cũng muốn tiện, mà tiện thì kiểu gì cũng có bất lợi nào đó, framework gì cũng thế thôi :D
Thế thì ổn.
 
Theo mình thấy thím viết mọe 1 cái Middleware cho nhanh, tự mình custom. Bắn mấy cái config đó vào redis or vào đâu đó.
Tự mình handle bằng source thì mai sau thím dễ scale hơn, bản thân mình cũng code Java mà mình ít sài thư viện vl. Sài thằng spring boot chỉ là nó có sẳn tomcat k phải cấu hình :LOL:
Chúc thím ngon chym.
 
Thím check cái tokenService coi actual class nó là gì rồi debug vô.
Sao extract cái token cái scope ngộ nghĩnh thế kia :LOL:

"scope":"phone profile email"
 
Theo mình thấy thím viết mọe 1 cái Middleware cho nhanh, tự mình custom. Bắn mấy cái config đó vào redis or vào đâu đó.
Tự mình handle bằng source thì mai sau thím dễ scale hơn, bản thân mình cũng code Java mà mình ít sài thư viện vl. Sài thằng spring boot chỉ là nó có sẳn tomcat k phải cấu hình :LOL:
Chúc thím ngon chym.
THế thi code độn lên nhiều sau khó maintain lắm. hệ thống của mình lớn hàng trăm microservice, nên dùng những framework chính thống theo template của các service sau transfer người mới dễ và xử lý issue chung cũng đơn giản hơn
 
THế thi code độn lên nhiều sau khó maintain lắm. hệ thống của mình lớn hàng trăm microservice, nên dùng những framework chính thống theo template của các service sau transfer người mới dễ và xử lý issue chung cũng đơn giản hơn
Cái đó cũng tùy cảm nhận thôi bạn ak, Bản thân mình 7 năm code java, sau đó chuyển qua Go. Khi code Go hầu như phải config vs code toàn bộ. Cái chính là document vs tổ chức code thôi. Còn thư viện thì tùy định hướng của mỗi cty thôi.
Nói chung outsource thì mình thấy đa số sài lib nhiều, còn cty product nên build chắc nền móng.
 
Build new product càng phải xài thư viện. Time to market là key. Quan trọng là hiểu mình đang làm gì là dc rồi, thạo cái nào thì làm cái đó. Ngay cả Amz, FB những ngày đầu code cg 1 nùi monolithic, từ từ nó mới cải tổ lại.
Con cái project Spring trong thớt này có 2 phần, 1 cái Oauth2 Server, 1 cái Oauth2 client/Resource Server, thím thớt để chung lại nên rối rắm thôi. Giờ ngồi build 1 cái Oauth2 server/Identity Provider chắc chết, industry standard có sẵn rồi cứ lấy lib về customize lại thôi, xài SASS cg dc như Okta, Cognito, etc.
 
Back
Top