I am new to OpenID and OAuth2 and read several tutorials and references but there is one problem left open I hope you can help with.
Our existing application does RBAC with the addition of a complex system of functionality-grained access rights. This means, an authentication token must contain not only roles a user has, but also additional functionalities he is allowed to do. Example: A user that is in the role „Editor“ might have (or might not have) the additional right to execute a special function X. As our application is huge, besides lots of roles there are literally hundred of optional functionalities he could be granted or not. To our knowledge, this is not covered by any of the existing authentication services / products.
We did not find a solution for this in „pure“ OpenID Connect / OAuth2, so currently we discuss the following attempts:
Maybe there are other solutions to that problem, but we could not image them.
Any comments welcome (besides: do not use per-function-access-rights as this is axiomatic for our product)! 😊
-Markus
_______________________________________________
general mailing list
gen...@lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-general
Joseph,
thanks a lot for your kind answer. We really appreciate all ideas!
Actually we need to say that we are an ISV, so we are NOT in the position of selecting an IDP vendor. What we actually strive for is understanding the general OpenID / OAuth2 pattern, how we can integrate into ANY existing company infra structure for SSO. Our customers all over the world already have chosen their IDPs to implement SSO, so there is NO SINGLE IDP and no choice BY US. They expect from us that our highly complex per-function-grants still work well with their particular IDP OR that the IDP only does SSO but not authorization. In particular, they do NOT enforce to manage access rights within their IDP; i. e. it is OK for them to just create ID Token with their particular IDP, forward the ID Token to us, and let us do authorization on our own in a custom way (if no better solution possible).
Moreover, as we are dedicated open source committers, we strive for a free solution. So paying someone for answers on the OpenID / OAuth2 standards is out of scope for us. We do not have custom questions or product specific question, we only ask about the standards themselves. So we like to abstain from project-specific consulting / vendor-specific solutions.
Hence our questions more clearly actually are:
Thanks!
-Markus
Joseph,
thanks a lot.
Your comments all are very helpful!