Like the Kerberos tickets, is it possible to forward to another application:
a SAML assertion
an OAuth token
Thank you,
SAML Assertions: Yes, one such protocol is WS-Trust where the Security Token Service (STS) generates SAML assertions and they can be presented to an end service (i.e. relying party) that trusts the STS. Another is the "SAML 2.0 Bearer Assertion Profile" for OAuth - simply, the SAML grant type - in which you can present the SAML assertion (usually got through SAML Web SSO) to the OAuth endpoint and exchange it to an Access Token.
OAuth Tokens: I'm not sure about a standard use case for this.
Related
Implementing SSO in my application and from app-1 i need to make a rest call to app-2. Login in app-1 with SAML and authenticated successfully and trying for rest call from app-1 with openid but since authentication is using saml only so not able to get the access/bearer token. Please help how to get the access/bearer token from saml request/response. I'm using Keycloak Server for SSO implementation.
You can't.
REST API need a JWT token not a SAML one.
Change SAML to OpenID Connect and it will work.
(1) OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
(2) Presently there is no IETF draft document regarding SAML 2.0 Profile for OpenID Connect client.
We can refer to the IETF draft document SAML 2.0 Profile for OAuth 2.0 client.
The OAuth 2.0 Access Token using SAML Assertion filter enables an OAuth client to request an access token using a SAML assertion. This supports the OAuth 2.0 SAML flow, which is used when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML assertion, without a direct user approval step at the authorization server. For more details on supported OAuth flows, see API Gateway OAuth 2.0 authentication flows.
(3) Both Auth0 and open-source WSO2 Identity Server implement the SAML profile for OpenID Connect/OAuth to convert SAML token to OpenID Connect/OAuth token, as demonstrated by Auth0 SAML Configuration and WSO2 Adding and Configuring an Identity Provider. In other words, Auth0 and WSO2 Identity Server can relay SAML authentication provided by SAML IdP to either OpenID Connect client or OAuth 2.0 client.
Just started POCing KeyCloak to hook up LDAP for user federation (really easy!) and set up a SAML Service Provider with Node.JS (took a bit more time to get the config right). See POC
Question:
Using KeyCloak as the sole Identity Provider, is it possible to set up a 3rd party service (Appian) as a SAML Service Provider, and use the SAML Username and/or Token(session_index) it receives to request an OAuth Token?
Preferably the 3rd party (trusted) service, behind the scenes, would make the OAuth request (with a client id?) to get an access token, and use the token to make API calls.
Seems like there could be two KeyCloak clients, one for SAML, one for OAuth, but then KeyCloak would be able to coordinate the auth under the covers.
You can exchange a SAML assertion (NOT its decoded contents) for an oAuth access token. This flow is described in RFC 7522 (SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants). In practice, this is an exotic use case and it's hard to implement. It assumes that the requester (client) has a way to acquire a SAML response from the IdP and wield it to grab an oAuth access token. To top it off, there are precious few IdPs that support RFC 7522 exchange. At the moment, Keycloak does not support it.
A more straightforward variation of the use case you're thinking about is an ability of a client to request any token (SAML, oAuth, ...) from an identity provider/authorization service without reauthenticating. This is possible with some providers but these mechanisms are proprietary to each provider. For example, Salesforce Identity service allows various tokens to be obtained if you send a request with a Salesforce session ID in a specific format.
In case of OAuth 2.0 authorization code and implicit flow cases, on hitting the Authorization Url user is redirected to OAuth providers login page.
To avoid showing up the OAuth providers page in my application, can i make user to enter username and password in text fields and pass them as Authorization header of authorization Url and get back access_token from OAuth provider and use it for further requests ?
Is it legal, valid and feasible ?
Is it legal, valid and feasible ?
No. Not with the flow you are using right now. Implicit flow is not built for this purpose, so you cannot do it.
But, OAuth 2.0 provide you a dedicated flow for your requirement.
4.3. Resource Owner Password Credentials Grant
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged application.
As described in protocol, in this flow, your end user(resource owner) provide their credentials to client application. Client application call token endpoint with resource owner credentials to obtain access tokens.
Flow overview (From RFC6749)
Token request request (From RFC6749)
As specification mention, this flow is there to support old systems which are unable to fully utilise OAuth 2.0. For example clients which use basic authentication.
I'm currently trying to implement the OAuth 2.0 authorization code grant on a public client/native client (Android App).
Since it is impossible to store the client_secret on the device, I wanted to use this grant type with rfc7636 / Proof Key for Code Exchange by OAuth Public Clients (PKCE).
I'm using wso2 5.3.0 IAM in the backend.
The Authorization step works perfectly fine, but I'm not able to get the Access Token without a client_secret: invalid_request, Missing parameters: client_secret
Did I misunderstand the authorization code grant with PKCE wrong or did I miss some configuration in the IAM?
In comparison: It is possible with auth0.
Best Regards,
Robert
Even if you use the authorization code flow, client_secret is required at the token endpoint if the client type of your application is confidential. "4.1.3. Access Token Request" in RFC 6749 says as follows:
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
So, change the client type of your application to public. I don't know WSO2, but I guess that it provides settings menu to switch the client type like below.
(screenshot of Authlete's web console)
The definitions of confidential clients and public clients are described in "2.1. Client Types" in RFC 6749.
Yes, the client_secret is mandatory in WSO2 IS implementation due to the Apache OLTU library that has been used internally to implement the OAuth2 feature.
Currently there is no way to register an application as a public client as explained.
However that doesn't mean there are necessarily any security pitfalls. Basically what the recommendation says is, not to embed the client_secret in a mobile app, because it makes it vulnerable. It doesn't provide any additional security for protected backend resources, because the client request is anyway not authenticated using client_secret. If you just treat the "Base64(client_id:client_secret)" as one single string it doesn't make any difference in the protocol or security of the protocol.
So when using WSO2 IS with mobile applications, following recommendations need to be followed.
Use authorization code grant type, which requires the client_secret.
Use PKCE (after WSO2 IS 5.2.0)
If you have other type of clients or channels for the same applications, e.g. like web, then register them as a separate service provider in IS and generate a separate pair of client_id, client_secret for them.
Disable "client_credentials" grant type for the particular OAuth2 mobile client you register in WSO2 IS, so that those apps can't get an access token without user authentication.
Going one step further, if you need to have unique client credentials for each instance of the mobile applications then use OAuth2 Dynamic Client Registration (DCR) to generate client credentials on the fly.
By following above 5 recommendations, it gives you the same level of security as recommended in the specification.
For Authorization grant flow you can send the request with empty client_secret. Try putting empty string like this client_secret='' and it should work as expected. You cannot request TOKEN_URI without client_secret parameter.
PKCE is used to protect theft of authorization code, Authorization code is valid for 10 minutes, when auth code is redeemed for access_token we also send code_verifier to make sure the auth code is not stoled by someone. code_verifier and code_challenge are generated together and code_challenge is used while requesting for auth code & code_verifier is used while requesting for access_token
Is it possible to exchange an OAuth2 access token (or OpenID Connect id_token) for a WS-* SAML token?
Here is our specific scenario that we would like to accomplish:
A user has been authenticated using an OpenID Connect endpoint and issued an id_token.
The same user has been authorized using an OAuth 2 endpoint and issued an access token.
A single-page application (SPA) requests data from a secured ASP.NET Web API and it sends the id_token and access token.
Here's the question/tricky part: We would like the ASP.NET Web API to fetch data from a WCF service that is secured using WS-*, so the WCF service requires a signed SAML token.
Is it possible to exchange the OpenID Connect id_token and/or the OAuth 2 access token for a SAML token that conforms to WS-* specifications?
We would like to use ADFS on Windows Server 2016, but we're also open to other secure token services (STS), such as Azure ADFS, etc.
It seems that you could implement access token exchange in your OAuth server as there is nothing in the spec strictly forbidding it.
OAuth doesn't make any explicit specifications for what shape your access token or refresh tokens are in. So you could use WS-* or whatever suits your client/RP needs.
You could use any of these types of tokens:
WS-Security tokens, especially SAML tokens
JWT tokens
Custom tokens
The id_token itself MUST be a JWT, however.