I just create my first Okta application using a dev account.
The app supports saml2.0 to authenticate user.
My goal is to make Okta app as a smal2.0 IdP and having my on-premiesis web app acting as a SP. The flows works great.
As first step to test the flow I created a "user base"(people) in Okta.
Would it be possible to engage from Okta app a custom api (on-premesis) to validate the user credentials (supplied within the Okta built-in login page)?
IOW I'd like to use Okta app simply as saml2.0 IdP, managing the saml2.0 protocol, but I'd like to keep the user base locally.
We do provide SDKs to interact with our API, and you can find them at http://developer.okta.com/docs/sdk/core/api.html.
For instance, the Okta Music Store available at https://github.com/okta/okta-music-store demonstrates how you can authenticate Okta users in an ASP.NET MVC app and automatically provision them into a local database "on the fly" when they sign in.
I hope this helps!
Related
I will draw a scenario, and need some suggestions:
I'm using Azure AD (v1.0 endpoint), a single-page app (SPA) and a web API. The SPA establishes the user's identity using OpenID Connect, authenticates the user and receives an id_token and access_token for the back-end web API.
Now, we don't want the SPA to do access control decision based on the id_token received within the SPA app.
Instead, the SPA sends the access_token to the back-end web API to access it, and now we want back-end web API to make an access control decision based on the roles claim found in the id_token, but which the back-end does not receive from the SPA.
The question is, is it possible for the back-end web API to send received access_token to Azure AD token endpoint and receive the relevant id_token for the user so that the back-end web API receives an id_token containing the roles claims for the user, in order to make an access control decision?
There are a couple issues with the approach as you describe it:
The app roles would be defined on the native client application (the SPA). Though you can technically define app roles in the manifest, you'll notice the Azure portal won't let you assign users or groups to a native client app. (Which sort of makes sense, because, as you've rightly said, you don't want to do any access control in the native client app.)
You can't do what you've described (exchange an access_token intended for one audience, for an id_token intended for a different audience). There are some variants of token exchange which you can do, but none of them would help you in this situation.
Instead, what you should do is define the app roles on the web API. Then, assign the users to the corresponding app role for the web API. When these users sign in to the SPA, and the SPA gets an access token on their behalf to the web API, you'll notice the access token will contain the roles claim, populated with the appropriate values.
Summarizing:
Under App registrations for the web API, define your appRoles in the app manifest (or on the Application object directly, using (for example) Azure AD PowerShell).
Under Enterprise apps for the web API, assign users and/or groups to their corresponding app roles, and choose whether or not app role assignment is required or not*. (Or do so directly on the ServicePrincipal object.)
Under App registrations for the SPA (the Application object), add the web API as a required permission.
*If you choose to require app role assignment for the web API (under Enterprise apps > Properties), the SPA will not be able to get an access token for users who are not assigned to an app role for the web API. If you choose not to require app role assignment , users who are not assigned an app role will be able to sign in to SPA and the SPA will be able to get an access token on their behalf for the web API, but the access token will not contain a roles claim.
I have a Web API registered in and secured with Azure AD. I am having a ASP.NET Core MVC Web application which consumes this API service. The controllers are automatically authenticated by use of Authorize attribute and I can get accessToken for current logged in user.
I am writing unit test for the UI web application. Can anyone help me with how to get Azure AD access token from unit test methods? Thanks in advance.
Since your unit tests probably want to run without user interaction, you need to use a different authentication flow.
Some APIs support username/password authentication, where your code has access to a set of credentials that can be used (see http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/).
If you want something a little more secure, you can use certificate based authentication. It is somewhat more complicated to setup and implement (https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential), but gives access to more APIs (e.g. Exchange Web Services user impersonation requires it).
Trying to get my head around the Identityerver4 setup for my project. I have a mobile app where users should be able to login with either facebook or username/password. Facebook login is implemented using the native facebook if available on the device. This results in a token from facebook. With this token I want to request an access_token and refreshtoken (hybrid flow) to access my api (resource). At the same time, some users will also log in unsing username and password.
As I need some info about the user, my plan is to user ASPNET Identity but I'm not sure how to make it wotk together with IdentityServer and If user profiles should be created in Identity based on both logins (registration). It seems obvious for the username/password login, but what about my social facebook login. Later there might also be a web client. So my basic question is how to handle the user registration with both setups
I am trying to use spring social for my REST services and my mobile app.
I wonder what the best approach is.
I am planning to use linkedin, google login and password authentication inside my mobile app. This social login should be connected to users in my database.
My spring application will act as an API which should be secured with a JWT token. The mobile app will afterwards use this JWT token to consume the API.
On my mobile I would like to have the possibility to sign up/sign in with linkedin, facebook or password.
As far as I understood mobile requires a different oauth flow than described in https://spring.io/guides/tutorials/spring-boot-oauth2/
Seems like it required the "Proof Key for Code Exchange" flow as stated in:
https://auth0.com/docs/api-auth/grant/authorization-code-pkce
Is this correct? I didn't find any information how to best do this with spring social and if spring social supports this use case.
Could someone point me in the right direction? I just found information how to do this with single page application and not with mobile applications. Thanks a lot in advance!
One possible way would be
The mobile app uses LinkedIn or Google's SDK to do SSO to retrieve an authN token.
The mobile app passes it to the backend service, which uses it to retrieve user details (e.g email) from the oauth service.
The backend service could do additional work about the user details (for example, link with existing users).
The backend service returns a JWT token to the mobile app, which ends the SSO.
The SSO should be able to return an email address for you to link users. Sometimes you need to apply for the permission explicitly (which Facebook requires).
The key point of this approach is that it avoids using the OAuth2 library completely in your backend services because it is now handled in the mobile app by using SSO provider's SDK.
The flow is summarized in the following drawing:
========
Edited:
We used this approach to do Facebook SSO with one mobile app and it worked very well. The mobile app was in iOS, and the backend service Spring Boot.
Discussion is welcomed.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.