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
Related
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.
i am newbie to the WSO2 identity server 5.0 service pack one.
I've been so confused lately that, what is different between identity provider and an outbound authentication?
How can i usage each of them ?
if i define a custom user store authentication, when must be used a custom authentication in Authentication endpoint? what is difference and usage each of them?
Identity providers are providing identity for users to interact with a system. As an example here in wso2 identity server we can configure Facebook as an Identity Provider(IDP). By doing this we can allow users to be logged into Service Providers using facebook credentials. you can follow the blog in [1] to test Wso2 IS with facebook IDP. Otherthan facebook we can use google, Live, Yahoo, etc. as IDP with IS.
[1] http://prasadtissera.blogspot.com/2014/04/login-with-facebook-for-wso2-identity.html
Thanks
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.
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.
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