Could anyone explain what would be the best approach for this scenario?: There are 2 separate Service Providers:
System A is a server that works as a rest API for a mobile application.
System B is a website which login is handled with simple and plain cookies.
I have read a lot and Ive found that the most used protocols in use right now for these kind of systems are SAML and OAuth, where OAuth works specially to give security to API services and SAML for web applications (cookie based).
Ideally, what is being looked for is a single log in, which is right now handled for System B through cookies in the main domain.
Is there a way to use both SAML and OAuth? Or What would be a good way to go?
The answer depends on what IDP you currently have.
Is the IDP SAML based or is that just what you got from researching?
SAML and OAuth don't really play well together.
The ideal would be OpenID Connect where you could use the OpenID Connect token to get a REST API token. But that would involve using the same IDP for authentication for both.
It depends, If you have both app deployed on same server then you can use SSO with tomcat valve or JBOSS with picketLink. If your applications deployed on different domain then you need to use federation server with SAML like OpenId, OpenAM, Spring-saml with ADFS or any other IDP server.
For securing rest API, you have to use Oauth protocol. By implementing OAuth you will get Oauth token by providing userId and password. Then Oauth token can be used to access rest API from mobile or any other third party service.
Related
I'm new to security and I'm trying to understand how to implement proper security without any overkill.
Below are my questions.
I don't want to allow 3rd party clients to use my API and hence I don't see any importance of OAuth 2.0. Hence I'm looking to use the sessions generated by keycloak (or Ory Kratos) in my Spring Boot Security. Any guidance on how to do that.
I have come across an application https://opstra.definedge.com/ which security is implemented using keycloak (can see the URL pattern). But in the requests, I can't see any JWT token in the chrome DevTools Network Tab while performing any network requests. I think they are implementing it the way I wanted. Any overview on how it is implemented.
I'm not architect at definedge, but I'm pretty sure they do not use Keycloak sessions in Opstra (they would have to run Opstra inside Keycloak servlet for that). It more looks like they use OAuth2 to authenticate users from a Java client and that this client has sessions of its own enabled (JSESSIONID cookie for opstra.definedge.com VS sso.definedge.com). It is quite possible that this java client uses access-tokens to authorize requests to resource-server(s), we just can't see it from the browser.
Restricting the clients allowed to consume your API has little to do with authorization method:
with basic authorization header, any client with login and password can access
with Bearer authorization header, any client with a valid token can access (which you already had anticipated)
even JSESSIONID cookie can be set for any origin (I believe), in which condition any request from the same browser would be authorized, whatever the web client.
Restricting your API clients is more about CORS configuration, which aims at just that: filtering which origins (host + port) can access which resource location (URL)
There is a notion of confidential client in Keycloak where the client must provide a password in addition to client-id to exchange authorization codes for access-tokens, but this does not apply to rich clients (clients running on devices you cannot trust): Angular, Vue, React, native mobile apps, etc. code can be reversed enginereed to read that password. But it is possible to configure a Java client of your own as "confidential" and as so, allow this client only to get access tokens to query resource-server (API).
OAuth2 comes with much more than just easing multi-client scenarios and JWTs with session-less java applications greatly ease horizontal scalability and fault tolerance. You should read this article for a refresher on
OAuth2 (and its value)
resource-server security configuration (with CORS)
I'm having a hard time figuring a good way to implement Oauth 2.0 and OpenID Connect authentication alongside an existing internal email+password authentication for a B2B Web app's API using Spring security.
We have a backend REST API that is a Spring Boot servlet application which currently authenticates users with OAuth 1.0 and the password grant. The front-end is an Angular single-page app through which users must log in with their username and password. The API's /oauth/token endpoint then delivers an opaque access token to be used for fetching secured resources that are then displayed within the app.
We'd like to add the possibility to log in using external authentication with OpenID connect, which is a perfect opportunity for switching to OAuth 2.0 and JWT tokens. Our API would then accept JWT tokens it delivered as well as external JWT tokens emitted by accepted issuers.
Reading and validating JWT tokens won't be a problem using Spring security's OAuth Resource Server. However things get complicated with how to make the classic username+password login flow work with JWT tokens.
We thought about delivering JWT access tokens the same way we used to with our old OAuth 1.0 tokens. The thing is, newer OAuth specifications advise against using the password grant, plus it simply isn't supported in the Spring authorization server project we're planning to use. The authorization-code flow w/ PKCE seems like too much for this case as we do not want the back-end API to render a login form but use credentials entered in the existing login form that is part of the single-page app.
I've read a lot about not using OAuth for 1st party login since its primary use is for external authentication, but again, that doesn't apply since we also want 3rd party authentication.
What would be a secure way to implement a Spring boot authorization server that can deliver JWT access tokens to a 1st party client in exchange for a user's credentials, all this using the existing log in page, and given the password grant type no longer being supported?
I thought about implementing a preliminary step that would be a POST request with Basic authentication to a /login endpoint that just returns a 200 HTTP status, then proceeding to the /oauth2/authorize request that would deliver the authorization code immediately without redirecting since my session is authenticated.
I'll be happy to provide more details if needed. Here are the resources I'm using for this project.
What about setting up an authorization-server capable of identity federation?
In such configuration, the authorization-server is responsible for providing with identities, proxying one or more sources (your existing user database for instance, plus maybe Google, Facebook, Github, etc.)
Keycloak does it for instance.
From the client point of view (your Angular app), the authorization-server is used to get:
access-token: put in Authorization header of requests to secured resource-server(s) (can be a JWT or an opaque string, doesn't matter, clients should not try to extract data from access-tokens)
refresh-token: send to authorization-server to renew access-token before it expires
id-token: get user-profile data (email, username, profile picture, etc.)
You should have a look at https://github.com/damienbod/angular-auth-oidc-client for connecting an Angular app to an OIDC authorization-server.
From resource-server point of view, access-tokens are the source ofr setting-up security-context, either by decoding and validating a JWT locally or with token introspection on authorization-server.
Have a look at those tutorials for such resource-servers configuration.
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
I have an angular 2 app, a Web API with OWIN Pipeline (.NET 4.6) and an ADFS 3.0. Every user who uses the angular 2 app needs to be authenticated and authorized via ADFS and if he's already logged in the domain he should be logged in to the Application automatically (Single Sign On)
Something like that:
I read tons of links and code on how to achieve that but I fail to put the pieces together.
As far as I understand ADFS 3.0 only supports OAuth 2 Authorization Code Flow which is either not supported or advised with a JS Application respectively on the Web per se.
I'm not quite sure which it is but the fact is I can't/shouldn't use it.
I understood that therefore I have to implement somekind of Authentication server on my Webserver where my Web API is (maybe IdentityServer 3 or something "homemade").
This lead me to think that I should use ADFS as an external login like google, or facebook which would lead to the following workflow
User requests token
Web API checks if user is already logged in to the domain
Logged in?
forward request to ADFS and verify.
ADFS returns OAuth Token to WebAPI
not logged in?
show login mask to user
forward request to ADFS and verify.
ADFS returns OAuth Token to WebAPI
Web API return OAuth Token to user
Is this even correct or am I completly off?
Anyway I fail to put the pieces to together.
I saw a lot of code which creates JWT Tokens in Web API (but doesn't communicate with ADFS) or communicates with ADFS via WS-Federation.
Additionally ADFS' OAuth 2 implementation seems to a bit special which adds another layer of complexity.
so my question would be:
How can I provide OAuth tokens to the user while authenticating against ADFS?
If you need any additional information I happily provide it
You will need ADFS 2016 which supports Single Page Apps that use Angular.JS. See https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/development/single-page-application-with-ad-fs for the flow and sample code.
You are right that ADFS 2012R2 only support authorization code flow which is only meant for native apps which are public clients to talk to a web api.
Thanks
//Sam (Twitter: #MrADFS)
I've been working whit the SAML extension to connect to an ADFS server. I've hacked the sample application to use my ADFS server and everything went well, but I would like to know if there is a way to connect to an IDP without using the loging page of the IDP. I mean if there is a way to do this process in background for the end-user. I am thinking about doing a query to ADFS or something like to get the users and do authentication from the SP login page, avoiding the need for the user to authenticate in the IDP login page.
The purpose of federated authentication is to delegate it to a centralized server in such a way that the relaying parties/service providers do not have access to user's credentials. Enabling authentication directly in your application would violate this principle and for this reason is not supported by neither Spring SAML nor ADFS.
If you want to authenticate your users directly, use authentication directly against Active Directory instead of ADFS. This will fully support your use-case.