Scenario A) User logs into a web application with a username and password. The username and password are validated against a WCF STS that generates a token that basically is the evidence / proof the user is who they say they are.
Scenario B) User is authenticated at the operating system level and logs into the web application with their Active Directory token, that is delegated to the WCF STS that generates a token that basically is the evidence / proof the user is who they say they are.
After Scenario A or B is completed, the user may request an operation that interacts with a WCF service that requires an STS token from the above STS service and is used to authorize the user to perform the requested operation.
Can I configure one STS service that can handle both the above scenarios and produce the same type of token as evidence that the STS trusts the user and is willing sign their token?
If yes, i need a sample. Urgent
Related
according to here (https://oauth.net/articles/authentication/) and many other things I have come across. OAuth is not meant to handle end user authentication. Reading through the article above and others while searching provides so much information at once from so many angles that it is hard to see through it all. ok...
Does this mean that...
A) The protocol itself is not intended to handle authentication, so therefore, OAuth client apps should inspect "who" can authorize users according to the OAuth providers?
If ONLY the user can authorize third party apps, then isn't the fact of receiving authorization from the OAuth provider in itself proof of authentication? (if this is the case, then can OAuth access tokens from places like Google and Facebook be trusted as authentications?)
B) OAuth client apps cannot trust authenticating users with OAuth, so therefore must provide another sound authentication mechanism alongside it?
If this is the case, then every site that I have clicked "Login With [provider]" (and no other complementary authentication scheme) has got authentication wrong?
It seems to me that if only trusted and specific OAuth providers are used, then this flow could infer authentication
App requests login with trusted providers
User is directed to provider to authorize (ONLY user can authorize)
App then requests and receives token from provider, and adds user to the app database if necessary.
Token is put into secure cookie or JWT and returned to the user to be presented on subsequent visits.
The purpose of OAuth2 access token is to delegate some access rights (scopes) from a user to a client application. So the application redirects the user to an authentication provider (OAuth2 server), which authenticates the user and asks the user (consent step) whether he/she wants to delegate some access rights (the scopes requested by the application) to the application.
If a client application receives an access token, it can get its meta data at the OAuth2 introspection endpoint - such as username of the user (resource owner). So this way, the OAuth2 can be used for authentication. But the main purpose of access tokens is to delegate some rights. For example if a third party application wants to save its data to a user's Google Drive, it needs an access token issued by Google with scopes that allow it to access Google Drive.
If you want to use OAuth2 only for authentication in your client application (to get identity of a user), you can use OpenId Connect (OAuth2 extension) and its ID token, which is in JWT format and contains information about the user that was authenticated the authentication provider. This is better suited for the "Login With ..." functionality.
In Single Sign On (SSO) scenario if all applications are running in same domain/company,
Is the same Security Token shared among all applications (relying parties) which get users authenticated from the same common identity provider / Security Token Service? What is the default behavior of any STS?
E.g. User A logs on to application X. After some time, she tries to access the application Y. Since she is already authenticated by the same STS and if the token issued to her is still not expired, she won't have to provide credentials while accessing application Y.
My understanding is that it may be possible if the token contains ALL the claims which would be required by all relying parties / applications. But is it a good practice?
Can token's (which was issued when user logged on to application X) expiry time be extended/reset when user A connects to application Y?
WIF implies ADFS usually,
Yes as long as all RP are using the same STS.
No - in ADFS, each RP has its own claims configuration. So the token produced is different (although you could simply copy the configuration if you wanted).
In WIF, yes. You need to use the "sliding token" mechanism.
Imagine a scenario where a desktop application calls a Single Sign On service to log the current user in. This service authenticates the user and returns a token (a Json Web Token) which is signed with the private part of a public/private key pair. This token has some claims about the identity of the user.
The application then wishes to call a different service for some data and so passes on the token to the service. The service uses the claims in the token (and the fact that it was signed by the SSO service) to identify the current user and to determine which data to return. So far so good.
Now say the application wants to provide some additional pieces of information which are not related to the identity of the user but some context about the current session the user is using in the application (like the current database they are connected to).
These seem like good candidates for additional claims which can be sent with the request, so the data service can extract the claims from the token and use both the identity claims from the SSO and the application specific claims from the desktop application to decide what to do and how to do it. (like which database to update)
The issue is that we can't add claims to the existing token as this has been signed by the SSO service and the application can't know the private key to sign the new token. If the original token is not present then the data service can't trust that the identity came from the SSO, so can't allow access to the data at all.
Options I can think of:
After authentication the application calls the SSO service again providing a collection of claims (secured in some way, not just anyone can call the SSO to get additional claims added to the token) and the SSO token, and the SSO service returns a new token which contains the identity claims and the additional claims the application wants to add
The application creates a new token which it signs and one of the claims in this token is to original token the SSO service provided.
Both of these have pros and cons, but on balance I think I prefer the first option.
To complicate things a little more, there is not just one 'application' there are a few. All will use the same SSO service, and all will want to add some additional application specific claims (ie the claims for app1 and app2 will be different)
Is there an out of the box solution for this problem already? Or are there other ways of dealing with this issue then the options outlined above?
Not sure I like either option.
After authentication the application calls the SSO service again
providing a collection of claims and the SSO token, and the SSO
service returns a new token which contains the identity claims and the
additional claims the application wants to add
I don't think any SSO service will allow you to do this. The claims in the token are signed as the SSO service guarantees they are correct. If the SSO service would start signing arbitrary data, that guarantee no longer holds.
The application creates a new token which it signs and one of the
claims in this token is to original token the SSO service provided.
If you let your application sign access tokens, you'll have to distribute the public keys of both the SSO service and the application. And your data service now has to trust both.
Why not just pass this extra info the data service may need as parameters in the service call? If you are calling the service over HTTPS, the integrity of whatever you pass is guaranteed.
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?)
I'm trying to wrap my head around 3-legged authentication to secure a restful API.
Currently I have a client application at app.host.com which needs to be accessed by multiple users with different account permissions and data, as well as the JSON RESTful api which holds all data at app_api.host.com
For 3-legged auth, I understand I first need a consumer key and secret belonging to the client app.host.com... I also understand an unauthorized request token must be provided by the service provider, which is given to the client, which is then redirected back to the service provider for authorization with a login dialog.
So does the login dialog then exist as a user interface on the API host at app_api.host.com? Doesn't this defeat the purpose of me building a purely JSON restful API separately to the client?
Or can I build the login dialog on the client which would then post the user/pwd details to another auth endpoint on the API and provide a 200 code when the request token is authorized? And then in turn the client would ask for permissions from the user which would again be posted to another endpoint which then responds with the appropriate access token for that user?
TL;DR: Am I able to have the login dialog exist on the client, which then posts data to the service provider? All guides I've read suggest having the dialog on the service provider, which in this case would defeat the purpose of having the api as a separate app altogether. How should I go about building this? Any available guides?
OAuth 2.0 defines different flows to use with different clients, depending on how much you trust the client.
Authorization code
The first and most secury flow is the authorization token flow. It is used with a traditional web application in which you can store secrets relatively securely (only people with admin privileges should have access to the client ID and secret stored in the configuration).
When the user (resource owner) wants to authenticate, the user-agent is redirected to the authorization server which belongs to the domain of the resource server (the data the client wants to consume, for example Facebook or Google). The authorization server presents the user with logon UI. When the user authenticates successfully, it presents the consent UI to ask if the user wants the client application to access the resource. If the user consents, the user-agent is redirected back to the client application with an authorization code. The client application can now use this code, its client ID and secret to talk to the authorization server directly and get an access token. In this flow, the access token is never in the hands of the user-agent.
Implicit flow
In the implicit flow, the user-agent (here typically a native (mobile) application or JavaScript client) redirects to the authorization server or opens a browser window to navigate to the authorization server. When the user authenticates successfully and grants permission to the client application, the access token itself is returned to the client. So the user-agent never sees the username and password the user enters (as this happens on a HTML page that is controlled by the resource server), but does have control over the access token.
Resource owner password credential flow
Here the user-agent is fully trusted and asks the user for username and password. It then communicates with the authorization server to get a access token. Even though the user-agent knows the credentials of the user, it only uses them once to get an access token. It does not need to send them along each request to the resource server.
So to answer your question, you can build the login dialog in your app if you think your users will trust your application enough to give you their credentials. Otherwise you should probably go for one of the other flows. You can read more on OAuth 2 here and here.