[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-18) API Authentication/Authorization not clear and should leave scope for other auth mechanisms
[ http://tools.oasis-open.org/issues/browse/CAMP-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31991#action_31991 ] Gilbert Pilz commented on CAMP-18: ---------------------------------- The DMTF Cloud Management Working Group had similar issues to us with regards to authentication mechanisms. On one hand, they wanted to specify a minimum required set of supported authentication mechanisms to assure interoperability. On the other hand, requiring a specific set of authentication mechanisms was seen as a barrier to adoption. The choice between HTTPS/BasicAuth, OAuth2, SAML, etc. is generally larger in scope than the decision to offer a CIMI or CAMP interface. Providers tend to try and homogenize their authentication interfaces across their offerings whereas CIMI and CAMP are only two of the many APIs that a provider is likely to offer. A provider that has decided to use OAuth2 is not likely to offer an API that requires the use of HTTPS/BasicAuth. After many months and much work, the DMTF CM WG eventually decided to say, effectively, nothing about authentication mechanisms. See Section 6 "Security considerations" of CIMI 1.0.1: http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf I recommend the same approach in CAMP. > API Authentication/Authorization not clear and should leave scope for other auth mechanisms > ------------------------------------------------------------------------------------------- > > Key: CAMP-18 > URL: http://tools.oasis-open.org/issues/browse/CAMP-18 > Project: OASIS Cloud Application Management for Platforms (CAMP) TC > Issue Type: Bug > Components: Spec > Reporter: Anish Karmarkar > Assignee: Gilbert Pilz > > The spec talks about basic auth requirement: > "Each request will be authenticated using HTTP Basic Authentication [RFC2617] unless otherwise noted." > (Above, what does "will" mean, is it intended to be a MUST?) > Unless I missed it somewhere reading the spec, looks like it does not talk about other authentication/authorization mechanism such as OAuth2. OAuth2 is still a draft but in practice its implemented/used by many. For example, if a "application developer", might be able to use OAuth2 access token[1] as HTTP Authentication header[2] or in some cases as URI query parameter while calling a vendor's CAMP APIs. > It sounds like the spec intends to mandate basic auth as the only authentication mechanism. Perhaps it should allow OAuth2 or other authorization/authentication mechanism as extensibility or keep it open and adopt OAuth2 as it evolves during spec development. > [1]http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-7 > [2]http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19 > [This issue was drupal issue # 1086] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]