Currently I have an SPA with multiple springboot microservices at the back (Resource Servers). Authentication and Authorization happens in the back using a Spring Oauth2 Server that serves a "Login Page" (Consent Screen) . Inside the Oauth server there is a ldapAuthentication provider that delegates authentication to an Active Directory and the rest (user detail and authorities) is fetched from a jdbc source from a custom data model (groups and privileges).
I have the requirement to start using Okta (enterprise). Conceptually speaking, do I have to remove completely the Spring Oauth Server and do everything with Okta regarding Authentication and Authorization? What would be the flow? What happens with the Bearer Token that I currently use? What happens with the introspection of each resource server when applying security access to requests? I am pretty confused what should be the Spring solution for Okta comming from a Spring Oauth Server.
Yes, Okta and Spring OAuth server are both authorization-servers, so you'll probably replace one with the other. The flow will be the same standard OAuth2 authorization-code flow:
"rich" client redirects users to authorization-server for authentication (Okta instead of spring authorization-server)
authorization-server redirects users back to "rich" client with authorization code
"rich" client exchanges authorization-code for access and optionally refresh and ID tokens
"rich" client sends request to resource-servers with access-token as Bearer Authorization header
resource-servers validate access-tokens and retrieves token claims (either with JWT decoder or introspection) and then evaluates if access should be granted based on token claims
You'll have to refer to Okta docs to add required roles (or groups or authorities and whatever you need in your resource-servers security expressions and that is stored in your LDAP and "JDBC storage") to Okta access-tokens.
If you really have configured your resource-servers with token introspection, you might have to switch to JWT decoding (I haven't search much, but it seams that Okta's introspection endpoint just returns a boolean: isTokenValid). You'll save a lot of resources in the process as JWT validation & decoding happens on resource-server only (it does not require a round-trip to authorization-server for each request as introspection)
You can replace your Spring OAuth server with Okta Authorization Server, which will require all your micro-services to change their configuration to do the introspection against Okta endpoints. Bearer tokens would be minted by Okta too.
Related
I've been going through this tutorial which shows how to secure a single page application using several scenarios going from simple to our own Authorization Server that delegates authentication to a provider. The first scenario uses the Authorization Code Grant to log the user in.
Suppose we replace Facebook's OAuth Server with our own in this case and configure it to return a JWT token.
Which OAuth flow should the SPA use if it wants to use the JWT token to secure requests through an edge server that load balances between resources servers?
Also how should spring boot / spring security be configured if we want to use the JWT token to replace the replace the default JSESSION and CSRF support in spring? IIUC the JWT token can be used as a replacement to both of these features.
Update
Based on Manish's answer assuming we are using OAuth 2 implicit flow we:
Put the #EnableResourceServer annotation on the Resource Server
Use an OpenID Connect client to implement the implicity flow
So once this is done are POST request secure assuming each request includes the JWT token as a Bearer Header, or do we need to also configure CSRF?
It will depend on how much your application is sensitive to security but Implicit flow is recommended for pubic client (SPA).
Tutorial is based Authorization Code flow and if you will replace Facebook with your STS, it will still use Authorization Code flow because #EnableOAuth2Sso store the JWT token on server and send the cookie to browser and it also uses refresh token to get the new JWT token. It is a customize flow to implement the Authorization Code flow with public client (SPA) based on API gateway pattern.
To implement the implicit flow - Do not use the #EnableOAuth2Sso at server side, just expose the REST API and secure it with #EnableResourceServer. And you need to use the oidc-client to implement the implicit flow link is here https://github.com/IdentityModel/oidc-client-js
CSRF protection is only required if you will store JWT token or session identifier in the browser's cookie.
We want to build one spring MVC based application which will support below use case:
User access the application URL to login into application.
Once the valid credentials are entered to login into application, the user can access any of the service provider application for performing SSO.
On the access of any service provider application the SAML response should be generated and post to the Service provider ACS(Assertion consumer service) URL.
Also in addition to IDP initiated SSO, it should also support SP initiated SSO where the authentication request will we posted to the application login page, after valid credentials are entered by user, the application should redirect to service provider(which have posted the authentication request).
The application should have its own login page and authentication mechanism, it should not redirect to any other identity provider for authentication.
Should we use normal Spring MVC based application which will generated the SAML response using open SAML library, or any other SAML builder can be used for satisfying the above use case.
This basically means
- your app bundles a SAMLv2 compliant IdP (please don't try to build one yourself based on some SAML lib)
- your app calls an API of the IdP for authentication and issues a session token the IdP will recognize later on (otherwise authentication will always happen again when another application (acting as SAMLv2 SP) wants to perform SSO
Issue with the latter: The "token" will most likely be a cookie and then the restrictions of the cookie spec apply. This means you can only use host-based cookies (which security mandates) if your app and the IdP are deployed behind the same 'FQDN' (e.g. by using an HTTP reverse-proxy)
Another issue: How does your app know when the show the 'login screen' if the user actually has a valid session with the IdP because SSO was started at a different SP?
SAML way: You would first have to do a 'passive AuthnRequest' to check this.
Conclusion: Your use case can be achieved, but the effort seems quite high. I'm not aware that there is some lib/framework, which would offers this at the moment OOTB.
I have used Owin in the past to create a token endpoint in my Mvc Web Api projects to provide oauth 2.0 tokens with "Resource Owner Password Credentials" grant type where access token provider would check a database user table to verify the validity of the credentials supplied by the mobile client (multiplatform App developed with Visual studio tool for Cordova).
In this project, the Web Api will be consumed by a multiplatform Mobile app used by Active Directory Windows domain accounts
I would like to use Owin Oauth 2.0 to grant an Access Token to these users but I don't know how to check the validity of these credentials.
What I was thinking is to put the /token endpoint behind "basic authentication" and in the code of the Access Token Provider get the user from the Identity that, in case of authenticated used, should be automatically created by the Asp.net pipeline.
Is it something that could work?
Do you know any better idea to use Oauth 2.0 for AD Windows Accounts?
Note:
I'm also investigating if Active Directory is able to provide an Oauth 2.0 endpoint by itself.
Here is a pretty good walkthrough of how to use Active Directory Federation Services to obtain an OAuth2 token.
https://technet.microsoft.com/en-us/library/dn633593.aspx.
You'll have to follow all the links at the bottom to get the entire walkthrough.
Note that it refers to using Windows Azure AD Authentication Library for .NET. But according to that documentation, that library is used for both Azure Active Directory and on premises Active Directory.
As for the workflow, once authenticated you'll be able to obtain and present a bearer token to your WebAPI. Your WebAPI then "validates the signature of the token to ensure it was issued by AD FS, checks to see if the token is still valid and hasn’t expired and may possibly also validate other claims in the token. At this point, the client is either authorized and the information they requested is sent in the response or they are unauthorized and no data will be sent." - https://technet.microsoft.com/en-us/library/dn633593.aspx
You could use ADFS 3.0 on top of AD which would provide you with OAuth 2.0 Authorization Server functionality: http://blog.scottlogic.com/2015/03/09/OAUTH2-Authentication-with-ADFS-3.0.html
Putting the token endpoint behind "basic authentication" does not help you because you'd be authenticating the client on the token endpoint, not the user. You could put the authorization endpoint behind "basic authentication" though.
I've read articles and seen example projects. I know owin allows to decouple application from web-server specific code, oauth allows third party clients to get access to application resources, and bearer token - client can get security token by login and password and use it as key for access to application resources.
I know that for simple cookie authentication using owin it's enough UseCookieAuthentication. But owin has this extensions: UseOAuthAuthorizationServer, UseOAuthBearerAuthentication, UseExternalCookieAuthentication, UseOAuthBearerAuthentication and I don't understand the full picture.
Could I use oauth without oauth bearer token (does it make sence)?
What are use cases for external cookie?
What are use cases for oauth (is it required only in case of client and server work in different domains using some api)?
What are use cases for oauth bearer token authentication?
Is it required oauth and bearer token authentication for web api only and for classic asp.net mvc applications it's no need?
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.