I wanted to know if it is possible to connect to an external database or service from the CustomGatewayJWTGenerator https://github.com/wso2/samples-apim/blob/master/CustomGatewayJWTGenerator/src/main/java/org/wso2/carbon/test/CustomGatewayJWTGenerator.java
Can we propagate ENV variables to the class, for example with the url of the service to invoke? How to know the service to invoke (depending if sandbox or production)?
Additionaly, is there anyway to access the OAuth scope in this class? Is it possible with JWTValidationInfo scopes?
Yes, you can pass an env value or a system property to this class.
Environment variable: Set the env value to the shell.
System.getenv("ENDPOINT")
System Property: When starting the server you can set the system property as ./api-manager.sh -DENDPOINT="https://localhost:9090"
System.getProperty("ENDPOINT")
You can get the key type which comes as production or sandbox as follows.
jwtInfoDto.getKeyType()
You can get the scopes from here.
jwtInfoDto. getJwtValidationInfo().getScopes();
Related
I need to add a WebRootContext to all the calls in the WSO2 Identity Server's Implicit Flow so that I can make calls through an API Gateway. I have managed to do this for all the calls I need by changing the
<WebContextRoot>/wso2-is<WebContextRoot>
property as well as changing the name of my webapp folders: wso2-is#authenticationendpoint and wso2-is#oauth2 endpoints. I can now successfully call http://localhost:9443/wso2-is/oauth2/authorize.
I also changed the endpoints in repository/conf/identity/identity.xml to include the wso2-is root context, specifically the OAuth2AuthzEPUrl, so that in the management console this shows up under identity:
However, after I login, the application calls http://localhost:9443/wso2-is/commonauth which has a return location of http://localhost:9443/oauth2/authorize?sessionDataKey=... and I can't figure out how to add my context root to the returning call. Where does the commonauth endpoint get the location it returns to? I'm assuming there is some property I need to set to make that happen, but I can't find it.
I also tried re-seeding the database with all my changes and this did not solve my issue either.
I looked in the source code here in github and couldn't find any references to commonauth or oauth2/authorize that stood out as to where this call is being formed. Any additional details would be greatly appreciated.
As per the official documentation, using a reverse proxy is the recommended way to add a custom context path to wso2 products.
However, as I wrote in another question, I could complete the implicit flow with local auth successfully with the mentioned configs in my answer.
I guess, what you are missing here is ProxyContextPath.
I'm running WSO2 5.7.0, using OIDC with the Implicit Flow. I have set the context root to wso2-is, so the authorize endpoint is located at http://MY_DOMAIN/wso2-is/oauth2/authorize. When I begin the flow with a GET call to the oauth2/authorizeendpoint, I am redirected to http://MY_DOMAIN/authenticationendpoint/login.do?client_id=MY_CLIENT_ID&commonAuthCallerPath=%2Foauth2%2Fauthorize....
The problem is that it drops the context root and so later in the Implicit Flow I am (incorrectly) redirected to http://MY_DOMAIN/oauth2/authorize, which fails because that URL lacks the context root of wso2-is. How/where in the code is the commonAuthCallerPath parameter set?
As per the official documentation, using a reverse proxy is the recommended way to add a custom context path to wso2 products.
If you are not going to use a reverse proxy, I would suggest the following steps to add a custom context path. But, note that I have tested basic authentication with oauth2/oidc only.
Set WebContextRoot in repository/conf/carbon.xml to /wso2-is to change the context path of the carbon management console
Set ProxyContextPath in repository/conf/carbon.xml to /wso2-is
Rename oauth2.war and authenticationendpoint.war in repository/deployment/server/webapps/ by adding a prefix wso2-is#
Update repository/conf/indeitiy/identity.xml all the relevent instances of the following pattern by adding the context path /wso2-is after the port
${carbon.protocol}://${carbon.host}:${carbon.management.port}/xxxxx
to
${carbon.protocol}://${carbon.host}:${carbon.management.port}/wso2-is/xxxxx
Update AuthenticationEndpointURL, AuthenticationEndpointRetryURL and AuthenticationEndpointMissingClaimsURL values in repository/conf/identity/application-authentication.xml by adding /wso2-is prefix
Restart the Identity Server
Do not forget that, this is not the recommended way in the documentation.
Rather than storing a credentials file on the server, we opted to use env vars to store the required info:
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_EMAIL
GOOGLE_ACCOUNT_TYPE
GOOGLE_PRIVATE_KEY
And we're obtaining authorization for a CalendarService as follows:
scopes = ["https://www.googleapis.com/auth/calendar"]
auth = ::Google::Auth.new_application_credentials(scopes)
service = ::Google::Apis::CalendarV3::CalendarService.new
service.authorization = auth
service.authorization.fetch_access_token!
Every part of the process works locally - authorizing, fetching an access token, interacting with API, etc. When we deploy to our staging environment on Heroku, we can't get past the following error:
Unable to read the credential file specified by GOOGLE_APPLICATION_CREDENTIALS: Neither PUB key nor PRIV key: nested asn1 error
I had seen this error in testing so I know it can be related either to a missing credentials file (like the error indicates) OR to an invalid id, private key, or email combination (because I was accidentally replacing the private key with an invalid value). In that situation, the error message was identical.
We have verified that all vars match the credentials used locally - what am I missing?
Make sure you are setting properly the GOOGLE_PRIVATE_KEY variable.
On Heroku to set a multi-line config variable you need to run:
heroku config:add GOOGLE_PRIVATE_KEY="$(cat private_key_file)"
An alternative to storing the key in a new file and using cat would be to use printf instead.
heroku config:add GOOGLE_PRIVATE_KEY="$(printf "-----BEGIN PRIVATE KEY.....")"
Have installed the API manager 1.4.0 on a single machine and got everything running. However have found the IP address shown within the management console and store sites are incorrect. For instance in the mgnt console home page the 'Host' and 'Server URL', also on an api's page in the store (both the URLs provides in the overview and the ip used in the 'try it' feature).
Looking into this it seems my network adapter is supplying a privately accessible ip, instead of public (this cannot be changed). This value is then propagated around the API manager on startup between components but also to provide links to access the services externally.
Have looked into the configuration and changed some values, however cannot get all IP's in the UI to display correct. Settings I've changed include..
repository\conf\carbon.xml HostName, MgtHostName, ServerURL
repository\conf\api-manager.xml APIGateway-->APIEndpointURL (also updated APIKeyManager-->ThriftServerHost)
Is there any way to solve this? In particular, is there a way to set an IP that will be published for external access without changing any configuration used for communications within the host?
Instead of an IP address, I would use a domain name, and add it first to your hosts file like:
192.168.1.2 apimanager.example.net
Then edit some carbon.xml parameters to look like:
<HostName>apimanager.example.net</HostName>
<MgtHostName>apimanager.example.net</MgtHostName>
<ServerURL>https://apimanager.example.net:${carbon.management.port}${carbon.context}/services/</ServerURL>
I am using the following form of the NetworkCredential constructor to set explicit credentials before invoking a webservice that requires a specific identity:
myWebService.Credentials = new System.Net.NetworkCredential(userName, password, domain);
This has been working fine in our IIS 6.0 development and IIS 7.5 staging environments where the various servers are part of our domain.
Now this code has been deployed to a production environment where the servers are NOT part of a domain but just members of a WORKGROUP and the proper authentication is not working. At runtime, this effective substitution is failing:
myWebService.Credentials = new System.Net.NetworkCredential("localuserName", "XyZ!XyZ", "myServerName");
I don't have complete access to these various workgroup machines and the sysadmin who configured things there appears to have set up the local accounts and application pools correctly.
So, in summary, can use of the above technique continue to work in a WORKGROUP by simply using the name of the server instead of the domain name? If the code should work in either case, then there must be some other configuration problem where I will have to chase down more information on the problem.
i'm using iis 7 and there is no problem with following:
1. find the ip address of machine which is running IIS and
find webservice bindings the bindings in IIS is like the following http://192.368.228.1:8051/
2. set domain like this : http://servername:port/ or http://machine-ip:port/
also you can set webservice url like the following
myWebService.Url ="http://192.368.228.1:8051/service1.asmx";
myWebService.Credentials = new System.Net.NetworkCredential("user", "pass");
no domain is used in this way.
for more information about this subjects have look on following link
this section: Passing Credentials for Authentication to Web Services
http://msdn.microsoft.com/en-us/library/ff649362.aspx#secnetch10_usingclientcertificates
hope this could be helpful.