cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8462) SAML: Auth plugin should handle authentication, admins to authorize users before they can authenticated
Date Fri, 10 Jul 2015 12:04:07 GMT


ASF subversion and git services commented on CLOUDSTACK-8462:

Commit 8bb0a70a56f652a271e21df892fcd1f4d8bd0f78 in cloudstack's branch refs/heads/4.5-shapeblue-samlonly
from []
[;h=8bb0a70 ]

CLOUDSTACK-8457: SAML auth plugin improvements for production usage

* Move config options to SAML plugin
  This moves all configuration options from 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

    * 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

    * Add HTTP-POST binding to SP metadata
    * Authn requests must use either HTTP POST/Artifact binding

    * 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.

    * 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
        - Stubs to implement saml token flushing/expiry

    * 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

    * Add new global config for SAML request sig algorithm

    * 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 <>

This closes #489

Signed-off-by: Rohit Yadav <>

> SAML: Auth plugin should handle authentication, admins to authorize users before they
can authenticated
> -------------------------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-8462
>                 URL:
>             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

View raw message