We are using the Spring-SAML extension to implement our SSO POC. I've got it working perfectly going against ssocircle.com as our IdP. We now want to bring the IdP internal, so we have chosen WSO2 as our I.S. I'm at the beginning/setup stage and the main issue I'm having is the "Certificate Alias" selection under "Register New Service Provider" in the web based management console. The Spring-SAML default config points to a JKS named "samlKeystore.jks". I'm still using this because I'm still in a test/POC mode. In order to register the SP for the WSO2 IS, I believe I need to be able to import the default cert used in samlKeystore.jks. I've exported the Apollo key and have imported it into wso2carbon.jks. The cert does show up in the Certificate Alias selection list, and I can select it. However, after saving, it always resets back to the wso2carbon.cert. I'm thinking something is wrong with my cert or the export/import procedure I'm employing. Does anyone have some insight here?
You have to check the Enable Signature Validation in Authentication Requests and Logout Requests in addition to selecting the alias. Otherwise the alias is of no use and won't be saved. (When there is no value saved for alias it shows the wso2carbon.cert by default).
Related
I'm not an expert but seems like one of the OpenID requirements is to have a /.well-known/openid-configuration endpoint.
Seems like Cognito is implementing this well as long as you don't use custom domain, e.g. point your browser to the URL below and you get a properly defined openid config JSON.
https://cognito-idp.{your region}.amazonaws.com/{your pool ID}/.well-known/openid-configuration
Now, if you use a custom domain try pointing your browser to the URL below, and you will see there is nothing but an error message:
https://{your poolname}.auth.us-east-2.amazoncognito.com/.well-known/openid-configuration
This is an issue because other apps/framework/library that rely on OpenID standards fail when trying to connect to a Cognito user pool.
Am I missing something?
Adding a custom domain doesn't change the issuer (iss claim in your tokens) and therefore the discovery URI is unchanged.
Your configured domain will be properly reflected in the configuration document (/.well-known/openid-configuration) and clients supporting discovery will be configured with your custom endpoints (authorization, userinfo and token).
I am attempting to connect to the Google Analytics API using Matillion ETL on an AWS EC2 instance in an effort to load a data lake.
When I try to add the callback URL into the Google Developer Console http://ec2-99-99-99-99.compute-1.amazonaws.com/oauth_redirect.html, I get the error:
"Invalid Redirect: domain must be added to the authorized domains list before submitting."
I do have amazonaws.com added to the Authorized Domains on the OAuth Consent screen. If I add, compute-1.amazonaws.com/oauth_redirect.html, it accepts it. So I know it's recognizing amazonaws.com, but not for my specific EC2 instance
I was thinking it was because it's a sub-sub-domain, but I'm not sure if that matters. Based on other posts such as this other people have been able to connect.
I've also tried adding a new record set in Route 53 instead of the AWS provided URL, but I don't know how to change the default callback URL in Matillion. I've sent their support team a separate question about that, and will let you know if that resolves it.
I do think this is a problem on the Google side that should resolve it though. Could there be some setting in the Google console that I'm missing to allow this?
Edit: Using the Route 53 URL instead when signing into Matillion will force the OAuth config to use that instead when getting the callback URL. I'm able to connect to Google Analytics now. I will leave this post up in case anyone else runs into the subdomain.subdomain.domain.com issue with Google
As suggested in https://stackoverflow.com/a/36112649:
You can use free DNS by http://xip.io/. So for IP 99.99.99.99 use
http://99.99.99.99.xip.io/callback. And it would be resolved to
http://99.99.99.99/callback.
Further, make sure the redirect URI in the .env file or other similar configuration in AWS is set to http://99.99.99.99.xip.io/callback.
I am just following what is on the guide
I've already populated the user's profile information but so far I only get sub. I want to get something same like in the guide:
{
"sub":"admin",
"email":"admin#wso2.com",
"website":"https://wso2.com",
"name":"admin",
"family_name":"admin",
"preferred_username":"admin",
"given_name":"admin",
"profile":"https://wso2.com",
"country":"Sri Lanka"
}
CONFIG
Identity Server - AWS Cloud with Domain and SSL + Nginx Proxy
Sample Web App - local machine
UPDATE:
It is an open bug. What
is the workaround to get the other fields? Based on that jira, only
the password grant is not fix, where to get the fix for code and
impilict grant?
I tried hosting the IS also locally, same results
To retrieve OIDC claim attributes to id_token or userinfo endpoint, the following steps needs to be done correctly(assuming you are working on IS 5.2.0).
1. Update relevant claims' Mapped Attribute with your underlying user store's matching attributes.
2. Update requested claims to Service provider [1].
3. Update missing attributes in '/_system/config/oidc' for scope 'openid' (Configuration changes in IS 5.2.0 [2]).
I am attempting to configure our WSO2 Identity Server (5.1.0) to talk to our Shibboleth Identity Provider v3 (3.2.1) server.
When I attempt to authenticate, I get an error in my Shibboleth IdP logs which suggests to me that my metadata for the WSO2 server is wrong:
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:334] - Metadata backing store does not contain any EntityDescriptors with the ID: MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:198] - Metadata document did not contain a descriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:281] - Metadata document did not contain any role descriptors of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:252] - Metadata document does not contain a role of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor supporting protocol urn:oasis:names:tc:SAML:2.0:protocol for entity MYENTITYID
I'm following documentation from the WSO2 site here:
https://docs.wso2.com/display/IS510/How+To%3A+Configure+Shibboleth+IdP+as+a+Trusted+Identity+Provider
I have the Shib IdP v3 working with other services, but a very new to that version and don't generally dig deep into Shibboleth anyway beyond setting up attribute resolution and release for relying parties.
Could someone with more experience in either the Shibboleth IdP arena or the WSO2 Identity Server arena point me in the direction of resolving this or at least narrowing down whether it's a general IdP configuration issue or a WSO2 metadata issue ?
The documentation from WSO2 site is based on Shib IdP v2.
You can still use it on v3, but you would need to enable v2 compatibility
https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration
There is no need though, the steps for v3 are quite similar.
AFAI can tell, Shibboleth does not support the unspecified name id format. It could be possible to tweak it to support it, but I have not found issues letting Shibboleth use the transient format. Likewise, I see reason to not use a persistent name id either. Thus, there is no need to modify the name id configuration.
The AttributeFilterPolicy is now defined on file /conf/attribute-filter.xml (or the attribute filter file loaded by /conf/services.xml). This policy specifies which attributes can be disclosed to each SP, so you need one entry for each of your SPs.
Since IS does not support metadata files yet, you need to tailor one and save it at /metadata/wso2is.xml The one in the WSO2 Site is a good start. Just keep in mind that the NameID Format does nothing if it requires the unspecified format, and that you might want to pass additional attributes in the SPSSODescriptor, in my case I had to add the following: AuthnRequestsSigned="true" WantAssertionsSigned="true". I also added the signing and encrypting x509 certificates that WSO2IS will use when sending requests to Shibboleth.
Next, you need to tell Shibboleth that you want to use that metadata file by adding something like the following to file /conf/metadata-providers.xml
<MetadataProvider id="wso2is"
xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/wso2is.xml">
</MetadataProvider>
Now, when you configure the IdP on WSO2IS, you need to map the claims/attributes that Shibboleth shares with WSO2IS (as defined in Shibboleth by /conf/attribute-filter.xml) to the WSO2 IS dialect. To do that, you go to your IdP configuration, expand Claim Configuration, then expand Basic Claim Configuration, there you can add as many claim mappings as you need.This is an example of the Claims Mappings
I hope this helps.
I'm currently working with WSO2 suite and I've been trying to do an example from wso2 official documentation server, that you can find here. I already configure everything step by step and when i run travelocity application in my localhost it looks like the example says, i click in the link and it redirects me to Identity Server login. I type in user and password, and then it redirects me to travelocity home page, but then i run into this error: SAML 2.0 based Single Sign-On
Error when processing the authentication request!
I check out the debuging log and it says that authentication succeeded and Identity Server sent the response to travelocity.
I have no idea what could be happening, please help me out.
I shared the log files here. My English is bad and i'm new working with WSO2, please be patient with me.
The logs at WSO2 IS side says Signature validation for Authentication Request failed. The possible reason could be that you have not selected the correct certificate alias at WSO2 IS.
To do that, edit your service provider's SAML configuration and update the Certificate Alias with the correct value. In default case it should have the value wso2carbon. In case you have configured it to something else, select the one you have configured.