I have an instance of WSO2 using CAS and SAML. They are both working and pull from the same identity source, Active Directory. I have multiple service providers, some use CAS and some use SAML. There is one thing stopping this from being a true SSO system. CAS and SAML don't work together.
If someone logs in with CAS, they have access to all CAS service providers (until timeout anyway). If they log in to a SAML service provider, they have access to all SAML service providers (< timeout). They do not have access to the other identity providers. If you log in with CAS, you have to log in again with a SAML identity provider, and the reverse.
Is there a way to log in with one and be authorized for both?
Let me echo your question again, just to verify whether I got it correctly.
You have WSO2 Identity server instance. There are multiple service providers(for your applications) configured. Part of them use SAML to authenticate. Rest use CAS.
If above is correct, true SSO should already be supported in WSO2 Identity Server. They had the feature lacking for SLO though, but I believe latest versions do have it.
What is the version you are using?
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.
We have tried configuring SAML on ADFS and want to know if you can choose to to integrate with AD using an LDAP Connection as a simpler approach, or will this not be an option if SAML is in place? We haven't had much success as of yet, and wanted to get other experiences or opinions.
If GCP has the ability to talk to a remote AD via LDAP (typically by installing a connector on the AD server or direct LDAP calls), that would be a possibility but it's not federation, you won't get claims and you won't get SSO.
To do this you need SAML.
There are two levels:
Adding LDAP as an identity store if you need an LDAP that's not AD. Otherwise use AD out of the box.
Setting up a SAML connection to ADFS by exchanging metadata and basing the claims rules on the identity store
I want to create a user in Wso2 (version 5.8) Identity Server and then populate it into my Service Providers automatically.
At this moment, after user registration in my Wso2, then I need to register the same user manually in each Service Providers (in my case, a SP is M-Files tool which provides a way to create user described here)
I am not sure if wso2 offers an automatic way to do this. I read the following documentation
Inbound provisioning: This approach is used for the opposite goal. Create a user in a Service Provider and with SCIM API I can create it into my wso2.
Outbound provisioning: This approach is very close that I want to but require relating the Service Provider with an Identity Provider (which must implement SCIM) and I dont want to use my Service Provider as an Identity Provider.
User store: I think it is not what I looking for. I think wso2 queries the external user store searching if the user which attempt to login is valid or not. I dont want my Service Provider act like a Identity Provider
Thanks
Outbound provisioning: This approach is very close that I want to but require relating the Service Provider with an Identity Provider (which must implement SCIM) and I dont want to use my Service Provider as an Identity Provider.
This is the approach you should be using. You don't have to use it as an Identity Provider. Just register it as an Identity Provider so that WSO2 can provision users to M-Files.
Regarding provisioning to M-Files, WSO2 support standard user management SCIM2 rest APIs. But if (I couldn't find any reference) M-files doesn't support such, you might have to find the API format that M-files support and then you can write a simple Java extension (Custom outbound provisioning Connector) to WSO2 Identity Server, so that it can provision users to M-files in a way that it prefers.
Documentation for customization
We're attempting to configure a relatively complicated WSO2 setup in which Identity Server (5.7.0 with KM) authenticates through an OAuth Service Provider, uses the token to secure API Manager (2.6.0) Endpoints, which then cycles through the Enterprise Integrator (6.5.0).
I've followed the steps to configure IS as the Key Manager (https://docs.wso2.com/display/AM260/Configuring+WSO2+Identity+Server+as+a+Key+Manager). This appears to be working, as I can see users in APIM that were configured in IS.
The problem is in the application. In IS I've created an OAuth POC that federates to another authentication provider. I want APIM to understand that application, and be able to use it to subscribe to APIs through the store for users that IS has given roles to. The application doesn't appear in APIM's applications, and I can't figure out how to link the two. I'd like for APIM to understand the token, figure out that it's for the OAuth POC in IS, and then if the user has that role, let them in, else return a 401 or something equivalent. Haven't been able to find someone else with a tutorial or guidance on this setup specifically.
Linking an Oauth2 provider from IS to an APIM application is called by WSO2 as "Out-of-Band provisioning". This guide may bring you a step further in your POC: https://docs.wso2.com/display/AM260/Provisioning+Out-of-Band+OAuth+Clients
I’ve made a new Identity Provider and setup it’s SAML2 authentication to our Shibboleth IDP. How do I “login” using this new setup?
The login link still goes to the IS login page, which is desirable because I need to login as admin to fix things, but is there another login link which will redirect to the IDP?
If you need to provide federated authentication for your applications. Your applications can be connected with Identity Server as service providers. Then you can defined your external IDPs a trusted IDP. Each service provider, you can select multiple IDPs as out-bound authenticators. There is some blog about that uses saleforce as trusted IDP, you can go through it as well
If what you want is to login to IS using Shibboleth as IDP, you should edit IS_HOME/repository/conf/security/authenticators.xml to enable SAMLSSOAuthenticator and configure it with the required details.
As best I can tell, there's not facility for testing an Identity Provider. The only way is to actually use it by setting up the full chain. In my case I setup API Manager as a Service Provider in the Identity Server, and selected the Identity Provider (mentioned in the original question) as Federated Authentication for that Service Provider. Then I changed the API Store to use SSO (pointed at the IS). Finally by attempting to open the store I was bounced to the IS, then immediately on to the Identity Provider.
Unfortunately there are a lot of steps in this chain and a lot of things that could be set wrong. I was hoping to find a method for testing this one part but as best I can tell there isn't such a capability.