1
votes

I am developing a mobile app in which I need to authenticate a user against Azure AD. Basically the user will be prompted their organisational email and password, which the mobile phone app sends to the backend server which will authenticate.

I have the 'public-client-app-sample' of 'azure-activedirectory-library-for-java' working, and can authenticate against 'graph.windows.net':

private static AuthenticationResult getAccessTokenFromUserCredentials(
        String username, String password) throws Exception {
    AuthenticationContext context = null;
    AuthenticationResult result = null;
    ExecutorService service = null;
    try {
        service = Executors.newFixedThreadPool(1);
        context = new AuthenticationContext(AUTHORITY, false, service);
        Future<AuthenticationResult> future = context.acquireToken(
                "https://graph.windows.net", CLIENT_ID, username, password,
                null);
        result = future.get();
    } finally {
        service.shutdown();
    }

    if (result == null) {
        throw new ServiceUnavailableException(
                "authentication result was null");
    }
    return result;
}

However, this does not return any userInfo (is null), and I can't figure out at this moment how to query to get a list with groups the user belongs to?

Do I just do manual lookups using the API using the tokens obtained from Adal4j, or is there a provided function within the library?

I am only starting with Azure, so it might be obvious, I might just be looking in the wrong places. I tried e.g. 'https://graph.windows.net/xxx.com/groups?api-version=1.5' but get 'Resource 'https://graph.windows.net/xxx.com/groups?api-version=1.5' is not registered for the account.'

1
What mobile platform are you developing against? Passing the username/password to your own service is not really a recommended approach. You can, instead, use one of the ADAL libraries (iOS, Android, WindowsPhone) to authenticate directly from the mobile device with AAD. - Philippe Signoret
I am both using iOS and Android. You are right off course, I haven't made my mind up yet. The main reason to pass the credentials (over a ssl connection off course) is that I only have one place to deal with the interface with Azure. However, for security, I can see that using the ADAL Libraries does have the advantage that you are only passing the keys along. - Luuk D. Jansen
Ok, I've provided and answer to (hopefully) all your questions, but really--I would not recommend this approach. My recommendation would be that you client apps use the corresponding ADAL libraries to get the tokens. This has another advantage in that you can secure access to your own API with this (sample for iOS, sample for Android). - Philippe Signoret

1 Answers

1
votes

First, you're absolutely right, adal4j was failing to return UserInfo. The reason for this was that the token request did not include the scope=openid parameter, which is required if the caller wants an id_token in the response. I opened an issue, and it has already been resolved. So, an updated copy of adal4j will fix your first issue of not getting UserInfo.

Now, regarding group membership for the current user: Normally, I would recommend that you simply configure you application to return the groups claim. This can be done very easily by changing the application manifest (downloaded and uploaded via the Azure portal, under the Application's configuration page) to include:

"groupMembershipClaims": "All",

Unfortunately, adal4j does not yet include the groups claim in the result of getUserInfo(), so that probably won't work much for you (issue opened, it really depends on how quickly it gets implemented, or if you want to implement youself).

Regardless, because it is possible for there to be too many groups to include in the token (indicated by , your application should always be able to use the AAD Graph API to retrieve the full set of groups the user is a member of.

And that brings me to the last point: adal4j does not implement a client of the Azure AD Graph API. So yes, you would have to implement that yourself (or perhaps use/modify an existing OData client).

(You can read more about Group Claims in this Azure AD blog post.)