A use case which I've seen been brought up in proof of concepts and client workshops, has been that of using an existing SAML2 IDP assertion as part of an authorization grant for an OAuth2 access/refresh token. OpenAM v11 provides support for the IETF Draft for SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants as documented in the Admin guide in chapter 13.
This sort of dance is becoming of more interest, as organisations look to leverage not only REST based services (which the OAuth2 endpoints provide), but also the increased use of mobile and non-browser based content delivery. SAML2 (whether that is dead or not is another blog...) is still pretty much omnipresent in federated landscapes, so being able to make use of existing investments in this area, whilst being able to build out REST based modular services is a very powerful concept.
OpenAM v11 can act as both the SAML2 service provider and OAuth2 authorization server in a single instance, making use of an assertion processing adapter class at org.forgerock.restlet.ext.oauth2.flow.OAuth2Saml2GrantSPAdapter which takes the IDP's SAML2 assertion and passes it across to the /access_token OAuth2 endpoint to respond with a JSON object containing the access token.
A few important steps - although these are documented - is to make sure the SP requests that the assertion is signed and also that the OAuth2 client name matches the SAML2 service provider entity name (ideally a URL, as a non-URL based name seems to cause issue).
Once the token has been retrieved, the /token_info could be called to verify validity or to retrieve associated scopes. It's also worth noting that the access_token lifetime is not related to the session lifetime at the IDP or SP side.