Hide Forgot
CURRENT IMPLEMENTATION Each webapp has its own login services, the shared bit is the j2ee session id. Client side login implementation exists at client side at webadmin and userportal. Single signon with jasper is incomplete, as no role transfer exist, so admin user should access the jasper directly. API supports only subset of authentication mechanisms. PROBLEMS IN CURRENT IMPLEMENTATION Logic of login is distributed among several applications. Implementation of challenges, password change is to be duplicated as well. Accessing services on different servers is not supported as the j2ee session id cannot be shared. Multiple identity in case of the Jasper interaction. NEW IMPLEMENTATION Single service webapp to perform authentication and authorization. All applications will interact with this service to perform authentication using either backend request or http redirect. If no good reason, implementation should be based on saml[1], there are java implementations[2], we can use these if are doing at least 80% of the implementation and we use at least 80% of their implementation. Authn and Authz should be done within the service, passing the entire principal record into application. The webapp implementation can be implemented as negotiate authn, this means that we should split the extension list into each application. REQUIREMENTS 1. Modify the jasper filter to be able to set roles. 2. Add roles to users: a. Login to application X b. Jasper admin WISH Limit the usage of users and groups table within engine, rely solely on the information obtained during login. Move authz sync code to aaa service, or better remove it completely. [1] http://en.wikipedia.org/wiki/SAML_2.0 [2] https://wiki.shibboleth.net/confluence/display/OpenSAML/Home
while the current SSO for VM isn't a great solution, we need to find a way to allow kerberos only to webadmin (and API), while allowing non kerberized login to user portal for the SSO to continue working. not sure if this RFE prevents this.
(In reply to Itamar Heim from comment #1) > while the current SSO for VM isn't a great solution, we need to find a way > to allow kerberos only to webadmin (and API), while allowing non kerberized > login to user portal for the SSO to continue working. > not sure if this RFE prevents this. Are there plans to improve that to be supported in the spice level rather than via the engine? Or any other plans to make it in a better way?
(In reply to Oved Ourfali from comment #2) > (In reply to Itamar Heim from comment #1) > > while the current SSO for VM isn't a great solution, we need to find a way > > to allow kerberos only to webadmin (and API), while allowing non kerberized > > login to user portal for the SSO to continue working. > > not sure if this RFE prevents this. > > Are there plans to improve that to be supported in the spice level rather > than via the engine? Or any other plans to make it in a better way? please discuss with michal and david blechter
moving to 4.0, wasn't delivered feature freeze
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Verified with: rhevm-4.0.0.5-0.1.el7ev.noarch