How to generate Authentication Token in Cognos Analytics 11.x - cognos

I am very much new to IBM Cognos. I want to fetch the metadata from Cognos env.(cloud/on-prem) to my java application. Metadata like reports, dashboards, data sources, namespaces and etc. I am ready to use Java SDK or REST Services. So I want to know how to Authenticate from Rest Interface and is there a way to create client id and client secret or should I just have to just get the Authorization token based on Username and password and use that token in consequent calls. Or if in Java SDK, please let me know from where can I get the sdk. Whatever the way, please help me to get forward.
Thanks,
Kranthi kiran.

There is a host of knowledge about accessing Cognos via the SDK available in the Cognos SDK documentation. The SDK JARs can be found in the Cognos installation itself (<Cognos root>/sdk), but you will probably want a little orientation from the docs to get started.
The above references the traditional Cognos SOAP SDK (accessible via Java). Cognos does offer a REST API, but it does not access all the various objects' metadata yet (as of 11.2).
For authentication, specifically, this will depend a little on whether you have a traditional namespace like LDAP or Active Directory (or even a Custom Authentication Provider). In this case, you'll wind up logging in to Cognos using the username and password, at which time Cognos will issue a CAM passport token. This token can be used for the remainder of the session. If you have an OpenID Connect namespace (e.g. Okta, ADFS, IBMid, etc.) things get a little more complicated.
IBM Cognos Analytics introduced support for two factor authentication protocol through OpenID Connect (OIDC) namespace. More information on Cognos OIDC configuration can be found here: Configuring an OpenID Connect namespace. Many Customers have existing automation applications or integrations through Cognos SDK or REST APIs. When moving to two factor authentication they struggle to implement logon to their OIDC namespace through the SDK. Depending on the OIDC provider, there are two main cases:
OIDC provider supports password grant, like OKTA:
...
OIDC provider does not support password grant, like IBMId.
Source

Related

Centralized identity management with different providers

I am going to build a web application that allows users to sign in with their Google or Twitter account. I think OpenID Connect(OAuth2) is the standard today to verify the identity.
I also want to provide several API services that can be only accessed with a valid access token from either Google or Twitter.
For example, all the four API's above are going to be public and so I have to protect from unauthorized users. For NodeJS based API services I can use http://www.passportjs.org/ to protect all APIs.
Assume, in the future the number of API's will be grow for example up to 20 API's and sign in with Facebook account will be also allowed.
Again, all the API's have to be protected and I have to do it 16 times with http://www.passportjs.org/.
In addition add the new provider Facebook, I have to do the changes on all 20 APIs.
The question is, is their a way to keep centralized, which means in the future when I will provide more the providers for example GITHUB for sign in I would like to do changes in one place not in 20 places.
Is the tool https://www.ory.sh/hydra what I need?
These are perhaps the two primary features of OAuth 2.0 and Open ID Connect:
Federated sign in to your UIs via multiple identity providers and the ability to easily add new options such as GitHub in a centralised manner
Full control over claims included in access tokens, so that your APIs can authorize requests however you'd like
FOREIGN ACCESS TOKENS
You should aim to avoid ever using these in your apps. Your UIs and APIs should only use tokens issued by your own Authorization Server (Ory Hydra), which manages the connection to the Identity Provider. Adding a new sign in method will then just involve centralised configuration changes, with zero code changes in either UIs or APIs.
IF YOU DON'T HAVE AN AUTHORIZATION SERVER YET
Maybe have a look at the Curity Identity Server and its free community edition - use sign in with GitHub, which has strong support for both of these areas:
Many Authenticators
Many Options for Issuing Claims
EXTERNAL RESOURCES
One exception to the above is that your APIs may occasionally need to access a user's Google resources after login, by calling Google APIs. This would require the token issued by Google. It can be managed via an embedded token approach - though it doesn't sounds like you need that right now.

Azure AD Login/logout implementation for Spring cloud microservices

I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.

Azure Mobile App Authentication using Xamarin

I read these two articles 1.here and 2.here to find out what is best way to perform authentication against an Azure Mobile App when the API on the server is using Claims based custom authorization and the Xamarin client calling it is using the MobileServiceClient framework. I am unable to finalize which of the two examples in those links is the better way to go.
In the first link there doesn't seem to be any dependency on platform specific code like it has in the second link, which means I don't need to write any code in the Driod or IOS or Windows projects and can get away with doing everything in a class library itself.(Am I right here?)
Also, the first link seems to not require any provider like the second link does because I am invoking a direct service call to a Url. The second link on the other hand only seems to support Facebook, Twitter, MicrosoftAccount, Google and WindowsAzureActiveDirectory. The mandatory MobileServiceAuthenticationProvider parameter doesn't seem to provide for Custom Authentication against a sql server based User table. I am not sure about this part and cant find documentation that says otherwise.
If LoginAsync doesn't provide for Custom Authentication then its clear that I will need to follow the InvokeApiAsync route. If it does provide it then the question is: should I write platform specific(Droid/IOS/windows) code in each target project like in the second link or should I handle all the service calls in a class library as can be done in the example shown in the first link? In other words should I go with LoginAsync or InvokeApiAsync? Which of the two is the recommended way?
The first article shows off custom authentication, as you intimated. The second article shows off App Service Authentication, which has a known list. If you need to do a custom username/password, then go with the former. If you need to go with social auth or enterprise auth, then go with the latter.
My general recommendation is don't require the user to create yet another username unless you have to - which means social authentication for consumer apps and enterprise authentication via AAD for enterprise apps.
My other recommendation is to always use the client SDK for doing the authentication part. This allows you to follow the very latest practices from the provider (facebook, twitter, etc.) in respect to security, refresh tokens and other authentication requirements. Once you have the provider token, it's easy to swap it for an Azure Mobile token by using LoginAsync() with a token. See the Azure Documentation for information on this.
In all cases, you are going to need platform specific code - that means using the DependencyService (as in the second example) to execute your login code. I generally create a singleton class that wraps the MobileServiceClient in the PCL. Then create an ILoginProvider interface which has LoginAsync/LogoutAsync code in it to handle the platform dependency code. My singleton class then calls the DependencyService to get the code. You can find an example in my GitHub Repository that covers iOS, Android and UWP.

node.js claims/roles access control module

I'm building a new node.js/Sails application. Authentication is easy. I'm using a third party OAuth2 provider (Microsoft Azure, don't ask!) and passport.js.
I need to now implement resource authorisation. I don't want to use anything specific to my OAuth2 provider (Azure Graph API) incase I want to support other providers in the future.
I would like to implement a claims based authentication system but I'm not wedded to claims.
What is the best approach to authorisation in a large express/sails app? I need it to be fully dynamic and granular.
I have found node-acl which looks good but there doesn't seem to be much else to compare and contrast.

Securing a nodejs / sailsjs API with OAuth2

I have developed a REST API with sailsjs and I'd like to add OAuth2 authorization to secure this API. I'm quite new to OAuth and I'm not sure where to start.
I found several modules that could be used for this purposes, for instance oauth2orize and an example of its usage https://github.com/aaron524/sails-oauth2-provider-example but I do not fully understand how this is working internally.
Basically, I'll have several clients consuming the API I'm developing:
- clients that I trust and that I'd like to use with the "Resource Owner Credential Authorization"
- clients that I do not trust and that will connect using the Authorization Code flow
I was thinking of adding a trusted property to the Client model within the sails application and then when a user will log onto an application:
- he will have a direct access to its resources (case of the trusted application)
- he will be requested to approve or deny the application from accessing his resources (case of the untrusted application)
Is this a good approach ? Any pointers on how to select the corresponding strategy based on the client trusted level ?
UPDATE
I've setup the following project on GitHub, using several tutorial and projects I found.
https://github.com/lucj/sails-oauth2-api
This project is not functional yet.
I'm still not clear on how to select the correct grant type (authorization code vs resource owner's password) when the user consume the API through an application. How to integrate this check in the policies ?
I do not manage to create the link between the OAuth endPoint (/oauth/authorize, /oauth/token) and the call to oauth2orize. Any idea ?
I finally struggled with Oauth2orize, sails and passport and managed to integrate OAuth2 security of my API in the project: https://github.com/lucj/sails-oauth2-api

Resources