I have a WSO2 Identity Server which authenticates my users against an external provider (using the authorization code flow). To trigger the federation, I had to choose against "code" and "implicit" flows for my end users, because these are the only ones that trigger the federation.
Then I chose the "implicit" flow, the problem is that the scopes an user requires are not forwarded to the external identity provider, the only one that's requested is "openid".
How to forward scopes to a federated identity provider?
put "Additional Query Parameters" as "scope=${scope}" to forward scopes to federated Identity Provider as per request.
Related
I'm facing the following scenario:
There are several companies each one with its own OpenID Connect Identity Provider (IdP) which federates users from their respetive LDAP servers. These providers are used to perform SSO in the context of each company.
There's a requirement to create an application that offers a common login for all the users of those companies.
The idea is to provision or use an existing cloud solution (AWS Cognito, Google Cloud Identity, etc., ...) that offers a shared login screen but delegates/federates the actual login to each of the company IdPs.
Are there any solutions that allows this?
Could you point at any documentation/guide to implement it?
This is just standard OAuth and OpenID Connect behaviour, with these 3 roles:
Application, uses OIDC to redirect to ...
An Authorization Server, which you own, and which redirects to ...
An Identity Provider
So you need a standards based authorization server and to configure your app as an OAuth Client. Then include the openid scope so that OpenID Connect is used. SAML based identity providers can also be supported in this flow, even though your app only uses OIDC.
The way to manage this with best usability, is for the authorization server to present a usernane authenticator, which captures a user identifier first, such as an email. It then runs some custom logic, such as a user lookup, to determine which IDP to route the user to. The user then authenticates at the IDP.
After authentication, the IDP issues tokens to the authorization server, which validates them, then issues its own tokens to the application. In particular the app gets an access token whose scopes and claims you can control. Your app can then send these to your APIs, which can authorize access to business data correctly.
Aim for behaviour similar to that above, or adjust it based on your preferences. Then trial it, eg with a cloud or Docker based authorization server, and ensure that you select one with sufficient extensibility to meet your requirements.
Note also that Stack Overflow answers should not recommend particular vendors, so I have not done so.
There is a solution called cloudpods using which you can manage both on-prem and public cloud resources. Cloudpods supports integration with multiple cloud providers like aws, GCP, azure, alibaba and etc.,
Is there any OpenID Connect Identity Provider that can delegate autentication to other OpenID Connect IdPs?
Yes. https://github.com/apereo/cas is one. You can set it up as an OIDC identity provider and have it then delegate to as many OIDC Identity providers as you want.
Using Auth0 as an example of what I want to achieve, it is possible to create an Auth0 application and configure a SAML trust relationship to a service provider by downloading Auth0's Identity Provider Metadata from a Auth0 SAML2 Web App and supplying that to the service provider, and also uploading the Service Provider metadata to Auth0. Supplying some other configuration options such as application callback URL to Auth0 then allows federation to be achieved into the test service provider via SP initiated SSO.
I would like to understand if it is possible to build such a relationship with AWS Cognito using either SAML or OIDC, where Cognito would be acting as the Identity Provider. There seems to be a lot of documentation available providing instructions on how to use SAML to create a relationship to a third-party identity provider for a user pool, but I'm struggling to find any documentation or options within the console to configure SSO to a test service provider, for example no reference to Cognito Identity Provider metadata. The assumption that I am making is that Cognito is a service only for authorisation with your own applications (such as user login) and does not support SSO into other services in the way that I describe, and that if you wanted to use Cognito as a Identity Provider then I would have to connect my user pools to a service such as Auth0 to then build out the SSO relationship. Am I correct in this assumption? and if not, please help me to understand where in the documentation/console I should be looking.
I'm also aware that AWS SSO exists and that I could potentially link a Cognito user pool to that, however the user pool will be made up of clients, and my assumption is that AWS SSO serves to specifically support (internal/affiliate) employee access to AWS services and resources, and should not be used as a way to enable SSO to another service for customers.
The basic topology is like this:
WSO2 IS as my service provider and takes care of authorization via XACML, our existing internal IdP takes care of corporate authentication (SAML, Oauth2).
I'd like to receive a guidance about best practice how to configure an outbound Federation using the WSO2 IS as a proxy for SAML protocol. Is it correct to separate the user ID domain, by creating so a called "tenant" in order to route the SAML requests though an outgoing STS connection to an external primary IdP? Is this configured under Identity Provider - add Identity Provider - Federated Authenticators - WS Federation Passive Configuration?
Domains and Tenants?
As an example, I would like to configure an account like this. ID = falb#red.com, where the federated lookup will forward my request to the IdP responsible for the domain "#red.com". Is there any discovery, or smart routing mechanism available that is able to identify the "red.com" domain, without need of creating a tenant?
XACML Access?
In a more advanced scenario, once we have a federation between the WSO2 server and and external IDP, is a service provider, a web application server, able to dispatch a PEP request by attaching a SAML token, without use of preceding entitlement routines, like passage of login and password. Is there an entitlement routine in place that accepts SAML tokens at the PDP side and validates it though the SSO federation mechanism?
Thanks in advance for your guidance.
Regards
Claude
I can not understand the difference between identity provdier and resident identity provider.
Following blog(http://blog.facilelogin.com/2014/10/wso2-identity-server-500-resident.html) said that "If you are a service provider and wants to send an authentication request or a provisioning request to the Identity Server
(say, via SAML, OpenID, OpenID Connect, SCIM, WS-Trust) - what matters for you is the resident identity provider configuration.".
Identity Provider provide Federated Authenticators which has OpenID, SAML, Facebook and etc configuration.
But, resident identity provider also provide Inbound Authentication Configuration which it provides OpenID, SAML2, OAuth and WS-Trust configuration.
Of course, i know that resident identity provider's Inbound Authenticator just provide metadata (simple url and so on). But identity provider's Federated Authenticator have many option.
Because same configuration is existing, read only the WSO2 IS document or blog, i don't know the need of resident identity provider.
I want to know the difference and actual example.
I guess, it would be simple. Same as Resident Service Provider. WSO2IS also would acts a Identity Provider. Basically as a SAML2 SSO IDP, OpenID, OAuth2 Authorization Server and so on. Then configurations that are related them, can be found at Resident Identity Provider. As an example, if you take WSO2IS as SAML2 SSO IDP. Think, about the configurations that are related to the SAML2 SSO IDP. One thing is that, IDP url, issuer name and etc. There must be some place that we can configure those. Resident Identity Provider provide some UI configuration for it. However, Resident Identity Provider configuration does not contain all the configurations that are needed. But it provides some important/few configs. If you need to find out more configurations that are related to SAML2 IDP, you can find them in the identity.xml configuration file. identity.xml file contains the all the configuration that are related to the Identity Provider.
My understanding of SAML and WSO2 is very basic so sorry in advance. I'm wondering if access to a SSO service can be restricted to a subset of users?
Yes you can restrict the access to a SAML SSO Service Provider to a subset of users. This is an authorization requirement indeed. When the service provider redirects the user to the Identity Provider (in this case to the WSO2 Identity Server), the service provider can request claims about the user from the Identity Server (claims such as Role, Email, Age, Country etc). Then after successful authentication of the user at the Identity Provider, the Identity Provider will send those claim values to the SSO Service Provider along with the SAML Response message. The SSO Service provider can read these claims and can decide if should let the user access the service or not. (For example by looking at the Role claim, if use has a particular role then SSO Service Provider allows the user, if not refuse)
I think that according the SAML specification, Identity provider can return error state. It has an element in SAMLResponse dedicated to this -> Status. But WSO2 Identity Server (up to 5.0.0), as far as I know, doesn't automatically support this behavior. One should change WSO2 authorization code to achieve this behavior...
Source:
SAML 2.0 Overview - line 1131, chapter: 3.2.2.2 Element
<samlp:Response
...<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
**Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>**
</samlp:Status>
<saml:Assertion ...
Instead of Success IdP can return:
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
or similar... see:
SAML2.0 handling SSO error