[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449802#comment-16449802
 ] 

ASF subversion and git services commented on CLOUDSTACK-10327:
--------------------------------------------------------------

Commit 9a13227a78acb14d9fd4f9ad5246ce67396cef7a in cloudstack's branch 
refs/heads/4.11 from [~olemasle]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9a13227 ]

CLOUDSTACK-10327: Do not invalidate the session when an API command is not 
available (#2498)

CloudStack SSO (using security.singlesignon.key) does not work anymore with 
CloudStack 4.11, since commit 9988c26, which introduced a regression due to a 
refactoring: every API request that is not "validated" generates the same error 
(401 - Unauthorized) and invalidates the session.

However, CloudStack UI executes a call to listConfigurations in method 
bypassLoginCheck. A non-admin user does not have the permissions to execute 
this request, which causes an error 401:

{"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
 to verify user credentials and/or request signature"}}
The session (already created by SSO) is then invalidated and the user cannot 
access to CloudStack UI (error "Session Expired").

Before 9988c26 (up to CloudStack 4.10), an error 432 was returned (and ignored):

{"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":9999,"errortext":"The
 user is not allowed to request the API command or the API command does not 
exist"}}
Even if the call to listConfigurations was removed, another call to listIdps 
also lead to an error 401 for user accounts if the SAML plugin is not enabled.

This pull request aims to fix the SSO issue, by restoring errors 432 (instead 
of 401 + invalidate session) for commands not available. However, if an API 
command is explicitly denied using ACLs or if the session key is incorrect, it 
still generates an error 401 and invalidates the session.

> SSO fails with error "Session Expired", except for root admin
> -------------------------------------------------------------
>
>                 Key: CLOUDSTACK-10327
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: API
>    Affects Versions: 4.11.0.0
>            Reporter: Olivier Lemasle
>            Assignee: Olivier Lemasle
>            Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore 
> with CloudStack 4.11, since commit 
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to 
> a network CIDR), but also a regression due to a refactoring: every API 
> request that is not "validated" generates the same error (401 - Unauthorized) 
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to 
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
>  an API command reserved for root admins. When the user is not a root admin, 
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":9999,"errortext":"The
>  user is not allowed to request the API command or the API command does not 
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the 
> session is invalidated. Then the next API calls lead to an error "Session 
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
>  to verify user credentials and/or request signature"}}
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to