Premise:
I have an infrastructure where we have a custom RP-STS implemented with Windows Identity Foundation, providing SSO for a few websites. This STS communicates with the sites via WSFederation. This custom STS is about to be deprecated because the organization is adding an Open ID Connect Idp into the infrastructure.
The websites themselves (Episerver) contain all the custom made authorization logic already based on the claims the STS provides, and if we were to simply toss the STS we'd have to replace all of this logic.
Question:
What is the browser redirect flow to integrate our RP-STS to the openId connect provider in such a way that the end user browser gets a session for both our RP STS and the Open Id Connect IdP?
Personal thinking on how it might be doable (based on massive assumptions on how openid connect works), skip this if you know how to answer:
Website sends HTTP post to RP-STS containing username/password
RP STS responds to browser with redirect to OpenId Connect Idp (Redirect contains username / password, and a replyto address is set to the RP STS)
OpenId Connect Idp creates a local session (???) and responds with a redirect to RP STS, redirect contains auth_token. (I'm unsure of the parts that go into an openid connect login flow)
RP STS receives user token and gets / asks for user data, builds claims and builds local session
RP STS sends claims in SAML token via WSFed to RP site
Am I even close?
Further clarification:
I do not want to remove the existing STS, but abstract the new infrastructure change behind it so that from the end-user-sites perspective, identity objects and authorization logic will remain unchanged.
I need help specifically in seeing if the login/logout flow is doable between the STS and the Open ID Connect IDP
WIF and OpenID Connect are completely different protocols e.g. WIF is mainly browser based in the passive profile. The token types are different - SAML and JWT etc.
The way to do this is via OWIN (Katana is the Microsoft implementation). There are NuGet packages for both WS-Fed and OpenID Connect.
There are samples available for Azure AD - refer Microsoft Azure Active Directory Samples and Documentation that you could use as a guide.
OWIN would allow you to use both protocols.
In fact, have a look at IdentityServer3.
This is an open source STS implementation of both.
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 a working c#/dotnet Windows desktop application that does its work by hitting various web services in my web application. When the desktop application starts up, it prompts the user for username / password and then hits my login web service, which returns a session token.
I have a large-org customer with many users. That customer wants to provide authentication / authorization for my combined desktop / web application directly from their domain controller. They want single signon, so my desktop app doesn't prompt their users for usernames and passwords.
How can my desktop application retrieve a usable authentication / authorization token from Windows (maybe from the user's Security Principal object)? How can my web application validate that token so it can trust the desktop application and send it a session token?
(My web application runs in my environment, not in the customer's domain.)
With pure-web-app customers I do this successfully with SAML2 and Active Directory / Federation Services. The SAML2 dance gets my user's browser to POST a request to the customer's AD/FS server, which then POSTs a signed response back to my web app.
But I can't figure out how to do it cleanly from a desktop application. Any wisdom?
You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers
It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.
I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.
Tokens come in many different formats. For today’s .NET applications,
however, three kinds of tokens are most important. They are the
following:
User name/password token—This very simple token contains only two
claims: the name of some subject and that subject’s password.
Kerberos ticket—More complex than a user name/password token, a
ticket includes a subject’s name, the name of the subject’s Windows
domain, and other information. Kerberos tickets that are issued by
Active Directory also include an extension that contains security
identifiers (SIDs) that identify the subject and the groups to which
this subject belongs.
SAML token—The Security Assertion Markup
Language (SAML) is an XML-based language that is owned by the OASIS
multivendor standards group. Unlike the other token types that are
described here, a SAML token doesn’t have a fixed set of claims
defined for it. Instead, this kind of token can contain any claims
that its creator chooses.
As soon as the claims are available, they can be used by Windows, the
application, or both. The most common uses of claims include the
following:
Authenticating the user(...)
Making an authorization decision(...)
Learning about this user(...)
Kind of Authentication:
Domain Based Authentication (eg Kerberos tickets):
A domain-based application accepts only a single token format with a
fixed set of claims. One common example is a Windows application that
accepts only Kerberos tickets. This kind of application is easy to
create, and it works well inside a single Windows domain. The problem
is that this simplistic approach to digital identity is no longer
sufficient for many applications
Claim Based Authentication (eg. SAML tokens):
Unlike a domain-based application, a claims-based application can
potentially accept multiple token formats with varying sets of claims.
The token formats and claim sets that this application accepts are
determined by the application itself.
Identity Technologies
Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
Windows CardSpace
Active Directory Lightweight Directory Services (subset of AD services)
Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
Windows Authorization Manager (tools for RBAC - role-based access control)
Active Directory Rights-Management Services (RMS)
Because AD Domain Services implements Kerberos, the default token in a
Windows environment is a Kerberos ticket. To use this default, an
ASP.NET application specifies Windows Integrated Authentication, while
a WCF application uses an appropriate binding, such as NetTcpBinding.
In either case, the following figure illustrates how a Windows
application with clients in the same domain might use a Kerberos
ticket and AD Domain Services
First versions of AD FS only support SAML with web clients.
ADFS 1.0, supports only browser clients—a restriction that’s scheduled
to change in the technology’s next release.
Hope it helps.
I should preface this with the fact that I've never done this, so I can't give you exact code, but I can point you in the right direction.
You should be able to do this with ADFS and Windows Integrated Authorization (WIA). In a "pure web app", the browser sends the credentials of the currently-logged-on user during the authorization step. In your case, your desktop app needs to do everything that the browser would normally do. Either way, the setup on the web service side should be exactly the same.
In C# with HttpClient, this is the important part:
var httpClient = new HttpClient(new HttpClientHandler()
{
UseDefaultCredentials = true
});
Then, whenever your httpClient sends a request that is challenged with a 401 response, it will automatically resend the request with the user's Windows credentials. This is exactly what a web browser would do. So use that when you get the token.
You may have to send a user agent string in the request, since ADFS seems to limit WIA to certain agents.
Once you have a token, then use the token in your requests to the web service.
The key is that you're replicating what a browser would do. So if you have trouble setting up what the HTTP requests should look like, then access a GET request in your API from a browser and use the browser's dev tools to inspect exactly what the traffic looks like, and use that information to replicate the same request in your code.
Should be a simple matter of registering the app in the IBM Cloud and providing callback URIs for authenticating the user and returning control just like login with google or login with Amazon.
But I cannot seem to find the exact flow of steps involved.
--prasanna
I think the service you are looking for is App ID.
When you are developing a web application, you can use the App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.
App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code exchange step the tokens are always sent via a secure backchannel between the app and the OIDC server. This provides an additional layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.
App ID interacts with identity providers by using multiple protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory External link icon or Active Directory Federation Service External link icon, generally use SAML as their identity protocol. For Cloud Directory, the service uses SCIM to verify identity information.
Read this blog post for using a custom identity provider
For an in-depth understanding of the flow, you can refer to this link
We have requirement of build .NET based plugin/component for enabling Authentication against multiple IDP providers like ADFS, Azure AD and Shibboleth based on DB configuration. i.e, depending on the configurable parameter the anonymous user will be authenticated against any one of the IDPs like ADFS, Azure AD or Shibboleth IDP.
Our application URL ("https://www.contoso.com/ProcessToken.aspx") will be registered as RP Identifier in all of the 3 providers.
We won't make any web.config changes for any of the providers.
At run time, User will access common page(Proesstoken.aspx) who needs to get redirected to the any of the Login page URLs at the provider (ADFS, Shibboleth, Azure) for Authentication based on User Organization. (For ex: User A to ADFS, User B to Shibboleth etc)
After Successful authentication at the IDPs the user needs to get redirected by the provider (ADFS/ Shibboleth/ Azure AD) to the RP Url registered.
In the redirected page (ProcessToken.aspx), we are planning to get the security token and decipher the claims required.
The main intention is to decouple authentication away from application logic and it should be extendable to other providers in future.
PS: Considered options like OWIN Authentication Middle Tier, .NET Component etc.
Need guidance on How and where to start.
Have a look at IdentityServer 3 which implements this multi-auth scenario or OWIN : ASP.NET MVC application with multiple authentication options.
The main point is that you use NuGet to download all the protocols you require and than use OWIN to pull them all in via app.use.
You can configure ADFS to have Claims Provider Trust with the other IDP's Owin will acknowledge the authentication. The difficult part will be reading the attributes from the tokens. ADFS under the covers in conjunction with the Owin framework use ws-federation, I have not figured out how to read the SAML.
What gets confusing is that at one time the answer was WIF but now that 4.51 has been released, WIF was moved into Owin. The documentation for a multi-tenant application is sketchy at best.
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