[ https://issues.apache.org/jira/browse/CLOUDSTACK-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603121#comment-14603121 ]
ASF subversion and git services commented on CLOUDSTACK-8462: ------------------------------------------------------------- Commit 7310c2d4a10e6c9992cc5ce9fe81842cad7b2f9b in cloudstack's branch refs/heads/saml-pp-squashed from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7310c2d ] CLOUDSTACK-8457: SAML auth plugin improvements for production usage * Move config options to SAML plugin This moves all configuration options from Config.java to SAML auth manager. This allows us to use the config framework. * Make SAML2UserAuthenticator validate SAML token in httprequest * Make logout API use ConfigKeys defined in saml auth manager * Before doing SAML auth, cleanup local states and cookies * Fix configurations in 4.5.1 to 4.5.2 upgrade path * Fail if idp has no sso URL defined * Add a default set of SAML SP cert for testing purposes Now to enable and use saml, one needs to do a deploydb-saml after doing a deploydb * UI remembers login selections, IDP server - CLOUDSTACK-8458: * On UI show dropdown list of discovered IdPs * Support SAML Federation, where there may be more than one IdP - New datastructure to hold metadata of SP or IdP - Recursive processing of IdP metadata - Fix login/logout APIs to get new interface and metadata data structure - Add org/contact information to metadata - Add new API: listIdps that returns list of all discovered IdPs - Refactor and cleanup code and tests - CLOUDSTACK-8459: * Add HTTP-POST binding to SP metadata * Authn requests must use either HTTP POST/Artifact binding - CLOUDSTACK-8461: * Use unspecified x509 cert as a fallback encryption/signing key In case a IDP's metadata does not clearly say if their certificates need to be used as signing or encryption and we don't find that, fallback to use the unspecified key itself. - CLOUDSTACK-8462: * SAML Auth plugin should not do authorization This removes logic to create user if they don't exist. This strictly now assumes that users have been already created/imported/authorized by admins. As per SAML v2.0 spec section 4.1.2, the SP provider should create authn requests using either HTTP POST or HTTP Artifact binding to transfer the message through a user agent (browser in our case). The use of HTTP Redirect was one of the reasons why this plugin failed to work for some IdP servers that enforce this. * Add new User Source By reusing the source field, we can find if a user has been SAML enabled or not. The limitation is that, once say a user is imported by LDAP and then SAML enabled - they won't be able to use LDAP for authentication * UI should allow users to pass in domain they want to log into, though it is optional and needed only when a user has accounts across domains with same username and authorized IDP server * SAML users need to be authorized before they can authenticate - New column entity to track saml entity id for a user - Reusing source column to check if user is saml enabled or not - Add new source types, saml2 and saml2disabled - New table saml_token to solve the issue of multiple users across domains and to enforce security by tracking authn token and checking the samlresponse for the tokens - Implement API: authorizeSamlSso to enable/disable saml authentication for a user - Stubs to implement saml token flushing/expiry - CLOUDSTACK-8463: * Use username attribute specified in global setting Use username attribute defined by admin from a global setting In case of encrypted assertion/attributes: - Decrypt them - Check signature if provided to check authenticity of message using IdP's public key and SP's private key - Loop through attributes to find the username - CLOUDSTACK-8538: * Add new global config for SAML request sig algorithm - CLOUDSTACK-8539: * Add metadata refresh timer task and token expiring - Fix domain path and save it to saml_tokens - Expire hour old saml tokens - Refresh metadata based on timer task - Fix unit tests Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com> > SAML: Auth plugin should handle authentication, admins to authorize users > before they can authenticated > ------------------------------------------------------------------------------------------------------- > > Key: CLOUDSTACK-8462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8462 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SAML > Reporter: Rohit Yadav > Assignee: Rohit Yadav > Priority: Critical > Fix For: Future, 4.6.0, 4.5.2 > > > At the time of writing the auth plugin, I did not consider many security > issues. The current SAML2 auth plugin would automatically create users and > allow them inside CloudStack which in production could cause a severe > security issue, especially in environment with public IdP server infra such > as large institutions. Therefore, the idea is to let admin add/import users > manually or from LDAP and then allow them to be SAML authenticated. This > delegates the security issue and account creation/handling to the admin or > some other business layer/system. > The following scenario would be supported: > - Admin adds a user either manually or importing from LDAP etc. > - Admin can then specify (multi-select or through API) a list of one or more > users with their username (or any unique ID) to be allowed to be SAML > authenticated > Assumption here is that every SAML authenticated user would have a unique > username mapped into CloudStack. Edge case handling: In case multiple users > exist in CloudStack with the same username (could be across domains) and if > the admin enables SAML authentication for all those user account, then the > plugin would assume all the users as the same and allowed by the SAML > authenticated user. Then, upon log in, the user should be able to > select/switch between all such accounts under any of the domains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)