I am a little bit confused about the terms of authorization and authentication. I know what each term means but combined with different Single Sign-On services I've got some problems with a consistent terminology.
What I am confused about is that, for example, CAS ( Central Authentication Service ) is meant to be used for authentication AND authorizationk. For me authorization would mean, that there is a functionality in the implementations, so the server decides if the user gets access to a different service or not.
But as I've seen, for example in CAS, that authorization for them is only sending different user attributes to the service and it decides whether the user can access or not. But is CAS then really providing a authorization? Is this not just authentication and then giving some attributes to another service which then decides whether the user can pass or not?
tl;dr:
Is sending user attributes to a given 3rd party web service so he can decide whether the user gets a login session or not already authorization by the SSO service, or is it just helping the 3rd party service to manage authorization ( so the SSO service does NOT provide authorization, just authentication) ?
CAS is not an authorization service. it is build to support authentication with single sign on and it can not authorize anything, the only authorization part it can help u with is to send u some user roles as attribute and u can use those roles as `role authorization'. for more than role authorization u need to implement your own authorization system (maybe embedded in the application that is using cas as authentication?)
Related
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
We are tasked with building a WebAPI for a distribution company with a handful of re-sellers who already have websites of their own.
Re-sellers accept orders from their own customers through their own webservers. After an order has been validated, re-sellers want to automatically forward the order's data to the distributor. The re-seller's webserver would send a Request to our WebAPI with authentication and order data - there would be no user interaction for this.
I'd like to know if OAuth can be used for authenticating requests from a re-seller's website. Most everything I've read about OAuth seems to focus on a User interacting with a login, but our scenario is mainly machine-to-machine.
If not OAuth, what is the "typical" authentication mechanism of choice for machine-to-machine type communications?
There are 4 different grant types in OAuth2. The one that is most suitable to your use case is "Client Credentials" grant type.
The RFC 6749 states:
Client credentials are used as an authorization grant
typically when the client is acting on its own behalf (the client is
also the resource owner) or is requesting access to protected
resources based on an authorization previously arranged with the
authorization server.
Note the phrase "on its own behalf" as opposed to "user's behalf".
In this flow the client directly gets the access token from the authorization server by providing the appropriate client id and client secret.
I am currently being tasked with writing an RESTful API that we are going to release to our clients. I plan to use Web API 2 with OWIN middleware. The applications that will be accessing this can range anywhere from a Console app with no additional user authentication to full blow web applications that will involve user login and authentication.
One other requirement is that we need not only provide user authentication to control what data we will return, we also need to authenticate that the application accessing our API is allowed by our organization. So this requires us to not only validate the application invoking our API's but also the many users logging in via that application.
The goal is to use a bearer token technology like OAuth 2. I am not very familiar with OAuth 2 but after looking it over I don't see a way to facilitate a two part authentication like this. Ideally we would like to issue a clientId and a clientPassword and they would pass this in along with the userid and userpassword and we would then pass a token back.
Is this something that anyone has tackled before using OAuth2 or is this a job for a custom auth solution?
What you describe sounds like fairly standard Oauth2.0 scenarios so you shouldn't need anything custom.
For the web apps you could use the Resource Owners Password Credentials Grant. Which is a standard flow.
This allows your Oauth client to pass in its client Id and client secret along with a user's Id and password to your Auth Server which can then validate both the user and the client before issuing a token in response.
But I would recommend using the Authorization Code Grant which is probably the best option for web applications and it involves both the client and the user being effectively authenticated.
For you console apps, or any apps which are not user specific, you can use the Client Credentials Grant. This allows the app to authenticate and to get a token without a user.
If you need your API to be aware of the client application, the only flow you can't really use is the Implicit Grant which doesn't authenticate the client.
I'm trying to investigate possibility of using claims aware security in the system I'm developing. The more I read about all this stuff the more confused i get.
So i decided to describe what I know already and I would ask that You correct my statements. I got lost with all those protocols and technologies used.
Below is a simple diagram of my system. There are two services - a REST service implemented using WCF and an ASP MVC web application.
I know I need to get an STS which will be a trusted identity issuer for both of my services. I'll be using roles to differentiate certain levels of access.
The STS functionality might be accomplished by using ADFS (or is there anything more needed in addition to it) or WSO2 Identity Server.
By saying STS I mean a service which will get credentials from a client wanting to authenticate and will return a set of claims (which will beside other information contain the role assigned to the user). This set of claims will be in the form of a token.
On the diagram I marked different client types with different colors. No I'll try to describe what protocols/formats i think will be used. I am pretty confused on what is a format and what is a protocol. But let me try:
Red scenario: rich WCF client authenticates agains REST service
Request to STS will be sent using WS-trust (is there any other possibility in ADFS or WSO2?). The credentials might be in one of several forms such as X.509 certificate, password digest, kerberos, windows authentication, SAML token (this is used in federation scenarios, right?), and few other.
The answer to the client will be in a form of SWT token sent over OAuth protocol since this is the way we do it when trying to authenticate against REST services.
Does ADFS support SWT and OAuth? I couldn't find the information.
The client then send the token received from STS to the REST service. Once again this is SWT token on OAuth.
I guess as for the client code all can be easily implemented using Windows Identity Framework.
Green scenario: rich android client authenticates against REST service
All protocols/formats are the same as in previous scenario. Is there any framework which can let me easily implement this?
Blue scenario: user of web browser authenticates against ASP MVC web application
User goes to the web app's main page. The webapp detects that he isn't authenticated yet so redirects him to the sign on page on STS (the sign on page is on STS, right?).
and 3. STS authenticates the user and sends HTTP response containing SAML token and redirection to webapp. So here is HTTP used, not WS-Trusts.
Another question. In this web browser scenario there will be a cookie written on a client's machine. So whenever client will try to authenticate once again, he'll just send the cookie to sts to obtain the token. There will be no need to send the credentials. STS will issue a token basing on the cookie without any real authentication logic involved. Is that statement correct?
ADFS / WIF out the box only supports SAML tokens - no OAuth support.
ADFS / WCF uses WS-Trust.
The sign-on page is part of ADFS.
The answer is "Yes" to your last question but (at some point) it will expire and the user will have to authenticate again.
Update:
Have a look at Claims Based Identity & Access Control Guide