According to the Valence Docs,
Valence Learning Framework API calls are all made in isolation, by a known application, and by a known LMS user.
If I want to build an application that has admin access, I'm guessing that I would have to make a "service account" that has admin access, and have my application use the API as that user.
How would I go about obtaining a userId and userKey for users that aren't real people, and only exist for the application to connect to the valence API?
Once you create a Service Account, you need to manually harvest the user tokens using a utility such as the API Test Tool (https://apitesttool.desire2learnvalence.com/) to authenticate with your LMS. You then need to store those keys securely, and configure your LMS to ensure the user tokens are long-lived. Many systems have a token timeout of 30 days, but when a headless integration is in place like the one you're proposing, it's often a good idea to make the timeout infinite. You can contact Desire2Learn Support to verify the timeout value for the user tokens.
There's a similar question that addresses this issue as well: Authenticaton Method for Desire2Learn REST API vs SOAP.
Related
Please forgive my ignorance on this topic. I've been a developer for a long time, but there's a huge gap in my knowledge and experience when it comes to authentication & authorization protocols and proper handling of tokens.
We've got a whole homegrown suite that consists of:
4 web apps (2 in Ruby/Rails, 1 in Elixir/Phoenix, 1 single-page React)
1 image server (serverless app written as an AWS Lambda / API Gateway)
1 custom data API (also serverless Lambda / API Gateway)
We also have an Amazon Cognito User Pool connected to our backend identity provider to authenticate users and generate tokens.
All but one of these allow some form of anonymous access; the other is only available to logged in users. If a user is logged in, they all need to access the user's profile info from the ID token, preferably without initiating another auth flow. Our backend apps may also need to make use of the access token, but obviously we wouldn't be handing that out to to the SPA or public API consumers.
My first thought is to store the tokens in a key/value store on the backend, and have a short-lived, encrypted JWT containing a unique session ID set on the shared domain that all of the backend apps have access to, with the key stored in a config secret. By decoding the session ID, they can get what they need from the data store. The API would also refresh when necessary.
I also know that API Gateway can use a Cognito user pool as an authorizer, but I'm unclear how I would make that work while integrating it with the rest of our apps and requirements above. Sometimes requests to the API are made from the browser (in the React app, for example), and sometimes they come from the backend of one of the web apps.
The image server and API are used by our apps, but are also documented and accessible for other people to build their own applications on. But they would have to register their apps as OIDC clients to receive any profile info from logged in users.
I'd love some advice on how to make all of this work, or at least pointers toward resources that might help make it less dizzying.
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.
I configured an application on AzureAd to be multi-tenant, I chose to require all the permissions for Windows Azure Active Directory and Office 365 Exchange Online.
I can get a user to grant permissions, get access tokens, refresh them, OAuth works for me. I always used the "common" keyword instead of the tenant ID, because my app is multi-tenant.
Now, I would like to have (CRUD) access to a user's Mail, Contacts and Calendar with this token. Here is my problem: I am completely lost in all the possible API endpoints. Should I use: graph.windows.net, outlook.office365.com, graph.microsoft.com? This page seems to suggest that graph.microsoft.com is the Swiss army knife that would serve my purpose, but somehow I cannot find a doc that allows me to find the info I'm looking for. Plus, it seems under development and maybe too incomplete for what I want.
If I make queries against outlook.office365.com, I've got a 401 error.
If I put my access token in this token analyzer, it seems healthy although the scope field only shows the permissions I set in the AzureAd portal for Windows Azure Active Directory, not Office 365 Exchange Online.
I am kind of lost, any help would be welcome...
You have a choice:
Call the separate service apis - Your problem is that you acquired a token to call AAD, and then tried to use that to call Outlook - you need to make a separate call to acquire a token for outlook.office365.com through ADAL or through the token endpoint directly. The token acquired for AAD Graph can ONLY be used against AAD Graph. Similarly the token acquired for Outlook can ONLY be used against Outlook APIs.
Just to clarify - Azure AD OAuth can protect/secure multiple web APIs, including O365 APIs, Azure AD Graph, Azure Resource Management APIs, your own APIs and the new O365 unified API. In the first access token request, you specify the first resource you want/need to call. It doesn't have to be AAD Graph - i.e. it's not the default AFAIK. Based on what is consented to, you have the ability to request additional access tokens using the (multi-resource) refresh token. Vittorio's blog post which you link to in your comments does a great job explaining this.
Call the O365 unified API (which is in preview) and IS documented. See below. The beauty of the unified API is that you only need to acquire a token to call graph.microsoft.com and ALL the entities on that endpoint are available to you AND more. It removes the siloed nature of #1, and the requirement to get and manage multiple access tokens to call these different API endpoints. However #1 is currently GA, and the unified API is preview only at this time.
For more on #2 please see https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-overview and search for "unified" in the list of samples here: https://msdn.microsoft.com/en-us/office/office365/howto/starter-projects-and-code-samples
We are working on improving the unified API documentation. If you are making pure REST calls, then I recommend starting out with the API explorer (and try things like https://graph.microsoft.com/beta/me/events and https://graph.microsoft.com/beta/me/messages to get your calendar events and mail messages), OR the API sandbox (which can show you JS code snippets, and allow you to test your own easily enough). As you can see on the REST examples, to access mail and calendar features in the unified APIs, you should be able to swap the service roots from Outlook to the unified API ie - https://outlook.office365.com/v1.0 -> https://graph.microsoft.com/beta. On the JS sample - we will be adding more capabilities here and additional samples.
NOTE: Personal contacts available in outlook.office365.com are not available in the unified API yet.
Hope this helps
I have my APP ID / APP Key and using the PHP sample file I authenticate against our install of D2L. I receive back the UserID and UserKey to the sample page. I authenticate against the system with my Admin userid and password at this point, not a specific account for this. I can perform the WhoAmI and a couple other things, however, I'm looking at how I can authenticate a specific user into the system at this point for SSO? We have a custom portal and I authenticate users from it to our Angel LMS now. I'm looking to do that for D2L, authenticate the user that the portal has already validated and pass them into D2L My Home page. I have worked with a variety of API's over the years, but this one has been difficult and documentation seems limited. Any help would be appreciated.
If I understand you correctly, currently your LMS users employ the Angel LMS as an identity provider (i.e. it actually authenticates the users), and then the D2L LMS consumes that IDP's service in order to authenticate a user? D2L does support use of the Valence Learning Framework APIs when the D2L LMS is using another, third-party, service as an IDP, but the environment configuration can be somewhat tricky.
Essentially, the entry point for API authentication (the first step that an API client must take to get a set of user keys) calls an URL in the D2L LMS that then re-directs to the procedure to log in the user, passing a ?target= parameter containing the callback URL that the calling client provided when first requesting the user tokens.
Thus, in order for the SSO using a third party IDP to work for an API caller, that target parameter needs to be passed along in each stage of the user authentication chain, properly URL-encoded at each stage. The Valence documentation does provide an overview of this process.
If your particular LMS needs differ from one of the standard user-authentication scenarios, it's probably good to have your LMS Admins contact D2L's customer support desk and open an incident with them, specifically explaining that you would like to ensure that your LMS environment using third-party user authentication can be properly set up to use the Valence Learning Framework APIs.