AAA, authentication, authorization, accounting vs. AAA authentication, authorization, attribution in SAML.

Actually there are 4 A's Authentication, Authorization, Account Management & Audit Logging
https://www.pingidentity.com/en/resources/articles/authentication-authorization-audit-logging-account-management.html

yes it is accounting and geared towards presenting evidence and trails for sanctioning one-doings (vai activities occurring in authentication and authorisation) and their responsibility to account for the involvement specific to assigned role. To me, it is plain "turning" on audit trail and ensure diligence logging of activities (security, apps, infrastructure related) are their in the process for SAML.

SAML is more of authentication (include SSO and identity mgmt. - who you are) and OAuth is more for authorisation (resource access control-what do you need and want). The last "A" is what warrant such claims in the first two "A"s for further declaration and investigation if incident or audit happens.  You will come across in implementation using OpenID (SAML resemble) too. see

Which one to choose?

Following are the points which can be useful to consider which one to use among OpenID, OAuth or SAML or any of their combination.
•If the use case is to develop SSO where at least one partner is enterprise use SAML, otherwise use OpenID.
•If the use case involves mobile devices for API authorization then use OAuth.
•If use case requires a centralized identity provider the use SAML.

http://resources.infosecinstitute.com/saml-oauth-openid/

So, Openid, OAuth and SAML are complete separate concepts?

Does SAML cover authorization by default?

Best regards

SAML is just exchange format that all parties talking to one another can understand. It do not do the actual authn or authz. Specifically it state that all parties should conform and "speak" in a common form of language. It term it as "assertion" technically. It is just to meant for specific subject (or user) to proof its identity based on some claims. In its context, there s always the  identity provider (govern user claims) and relying party (only allow access to resource requested if identity provider "stamps" on those claims).

So as a whole it covers assertions like
1-Authentication Assertion: The assertion subject was authenticated by a particular means at a particular time.
2- Attribute Assertion: The assertion subject is associated with the supplied attributes.
3- Authorization Decision Assertion: A request to allow the assertion subject to access the specified resource has been granted or denied.

you can use either one - see this illustration for both

SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don't get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.

On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.
Both approaches have nice features and both will work for SSO.

OAuth2 provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds for interoperability with native applications.

http://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/

To sum up OAuth 2.0 is an authorization framework and SAML is an authentication framework. To bridge both in having the "best" of both world is not trivial. The one actual example for better clarity is SalesForce.com uses a combination of OAuth and SAML functionality to provide seamless SSO facilities for applications. https://developer.salesforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth

Staying with one is more straightforward for simplicity and either still works. I definitely go towards the eventual service (relying) provider advice and supported scheme so knowing what they support is key as well ...

So for SAML assertion,

"Authorization Decision Assertion" implies authorization but is it authentication for authorization?

I asked like that because you say, "SAML is an authentication framework". So, SAML has no power on authorization?

Best regards.