THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
| Table of Contents |
|---|
Bug Reference
https://issues.apache.org/jira/browse/CLOUDSTACK-7083
Branch
Version 1:
| Jira | ||||
|---|---|---|---|---|
|
Version 2:
| Jira | ||||
|---|---|---|---|---|
|
Branch
Version 1: saml2
Version 2: saml2-production-gradesaml2
Introduction
Purpose
Currently CloudStack has its own authentication mechanism, the two of which methods include username/password auth which is cookie/session-key based and another which is HMAC signature based that uses api key and secret key.
...
I evaluated many opensource libraries which implement the SAML protocol and the most widely used stable library was OpenSAML. It will be implemented as a plugin using OpenSAML.
The version 1 implementation shipped with ACS 4.5.0/4.5.1 is not production grade, only supports HTTP-redirect binding and has several issues with respect to security, compatibility, support and interoperability.
The version 2 implementation aims to produce a production grade SAML2 auth plugin has honours compatibility and interoperability, and supports more endpoint bindings with several widely used IdP servers such as Shibboleth.
Testing Consideration
For testing the plugin with CloudStack, we only need an IdP which can be setup locally using Shibboleth IdP software (https://www.testshib.org), or simply using one of the following free to use public IdP (discovery) service:
...
Version | Author / Reviewer | Date | |||
|---|---|---|---|---|---|
1.0 | Rohit Yadav / ACS-dev community | 14/July/2014 | |||
2.0 | Rohit Yadav | 12/May/2015 |
|
|
|
Glossary
| Term | Definition |
|---|---|
| Assertion | A part of SAML message (an XML document) which provides facts about subject of the assertion (typically about the authenticated user). Assertions can contain information about authentication, associated attributes or authorization decisions. |
| Artifact | Identifier which can be used to retrieve a complete SAML message from identity or service provider using a back-channel binding. |
| Binding | Mechanism used to deliver SAML message. Bindings are divided to front-channel bindings which use web-browser of the user for message delivery (e.g. HTTP-POST or HTTP-Redirect) and back-channel bindings where identity provider and service provider communicate directly (e.g. using SOAP calls in Artifact binding). |
| Discovery | Mechanism used to determine which identity provider should be used to authenticate user currently interacting with the service provider. |
| Metadata | Document describing one or multiple identity and service providers. Metadata typically includes entity identifier, public keys, endopoint URLs, supported bindings and profiles, and other capabilities or requirements. Exchange of metadata between identity and service providers is typically the first step for establishment of federation. |
| Profile | Standardized combination of protocols, assertions, bindings and processing instructions used to achieve a particular use-case such as single sign-on, single logout, discovery, artifact resolution. |
| Protocol | Definition of format (schema) for SAML messages used to achieve particular functionality such as requesting authentication from IDP, performing single logout or requesting attributes from IDP. |
| Identity provider (IDP) | Entity which knows how to authenticate users and provides information about their identity to service providers/relaying parties using federation protocols. |
| Service provider (SP) | Your application which communicates with the identity provider in order to obtain information about the user it interacts with. User information such as authentication state and user attributes is provided in form of security assertions. |
| Single Sign-On (SSO) | Process enabling access to multiple web sites without need to repeatedly present credentials necessary for authentication. Various federation protocols such as SAML, WS-Federation, OpenID or OAuth can be used to achieve SSO use-cases. Information such as means of authentication, user attributes, authorization decisions or security tokens are typically provided to the service provider as part of single sign-on. |
| Single Logout (SLO) | Process terminating authenticated sessions at all resources which were accessed using single sign-on. Techniques such as redirecting user to each of the SSO participants or sending a logout SOAP messages are typically used. |
...
- RSA/X509 signature along with
- Create/manage JKS Keystore, X509 keys
- Handle expiry time (as sent by SAML assertion for valid user), on expiry how auth/reauth should work
Implementation
...
Details
Version 1: Done
- Implemented as a separate SAML auth plugin
- The authentication layer was refactored as a framework to support pluggable authentication mechanisms such as SAML
- SSO/SLO works and is tested against https://openidp.feide.no which is also the default pre-configured ACS IDP
- SP XML metadata is listed using getSPMetaData API
- Global configs are created with saml.* namespace
- IdP MetaData is loaded when plugin starts using a provided url from Config
- Cryptographics signature verification is done on Response object when doing SSO
- Fixes CloudStack UI to auto unbox cookie values
- If users are removed from IdP, SSO will not work but recommendation is that admins disable the user account which is removed
Version 2: In Progress
- Support multiple IdP servers if a federated metadata is provided:
Jira server ASF JIRA key CLOUDSTACK-8458 - Support multiple endpoint bindings such as HTTP-Post:
Jira server ASF JIRA key CLOUDSTACK-8459 - Survey and support standard IdP servers such as Shibboleth 2.4+:
Jira server ASF JIRA key CLOUDSTACK-8460 - Ensure compability as per the saml2int.org standards:
Jira server ASF JIRA key CLOUDSTACK-8461 Don't depend on NameId for getting unique ID (it could be a non-static one like urn:oasis:names:tc:SAML:2.0:
...
nameid-format:transient), instead depend on an admin specified attribute:
Jira server ASF JIRA key CLOUDSTACK-8463 - Let admin add/import and configure the user, the plugin should only check authorization. In case of multiple allowed SAML users with same username, authenticated user should be allowed to use any of the available account in any domain:
Jira server ASF JIRA key CLOUDSTACK-8462 - Allow admins to save IdP metadata on filesystem or in DB:
Jira server ASF JIRA key CLOUDSTACK-8464 - Improve UI for SAML authentication, currently a button is visible if saml plugin is enabled. We need to have a dropdown list of IdPs in case of multiple IdPs.
- Address any open-ended questions and production usage
TBD Future:
- Answer open-ended questions
- Get some field testing done and fix any integration issues
- Document the improved plugin usageUI module at login screen (right now we don't want to add a button for SSO)
IP Clearance
- Dependencies:
- OpenSAML: Apache 2.0 license
Overview
Content Tools
Apps