I have an internal app that allows users to sign in using Azure AD. On authentication, a SAML assertion is returned. However, some of the calls that the application makes require a JWT. WHat is the best way for me to get a JWT when a user signs in? Or is there a way for me to exchange the SAML for a JWT?
Disclaimer: I'm not expert an any of this stuff; I'm still learning it too and struggling with a similar problem. That said, here is my understanding.
I'm pretty sure there is no connection between SAML and JWT. Not a surprise, given that SAML 2.0 dates back to 2005 and JWT got started around 2012. So it's logically impossible for the SAML spec to say anything about JWTs.
If my understanding is correct, you have two options:
Do not use SAML directly. Instead of interacting with a SAML IdP (identity provider), use OpenID Connect and OAuth 2.0 with a provider that acts as an authentication broker. Configure the broker to act as service provider to your chosen SAML IdP. Configure your application to act as relying party (OAuth terminology, I think?) on the authentication broker. Then your app is OAuth 2.0/OpenID Connect/JWT all the way down. Your only interaction with SAML is configuring an authentication broker. Main downside is now you have to select and pay for an authentication broker as well as a SAML IdP.
Write your own authentication/authorization service to consume SAML assertions and issue JWTs. This might be necessary anyways, depending on how you need to represent authorization info in your JWTs.
Related
I have several REST APIs which I want to secure with a federated authorization server. This page: https://oauth.net/articles/authentication/ suggests that OAuth2 alone is not enough for authentication and one should use the OpenId Connect extension to get it right.
However, I have the feeling that what OIDC does is only defining an identity endpoint and the related scopes and claims. If I don't specifically need these identity claims, what's wrong with using plain OAuth authorization code for authenticating a user and protecting resource? Or is OAuth2 only for delegating access to a client app which works on behalf of the user (which is not my use cas)?
Thanks for the inputs!
Most end user authentication related work occurs on the UI side of things, and of course involves Authorization Redirects, Identity Providers, Consent Forms and so on.
In terms of the code for a Secured REST API you instead perform the following types of action. This is primarily OAuth 2.0 behaviour as you say, though Open Id Connect endpoints can be useful:
Validate received access tokens from the Authorization Server
Read token claims to identify the authenticated user
To do this you may need to download token signing keys from the JWKS endpoint
Your API can look up further details from the User Info endpoint
Your API can use the metadata endpoint to get the above endpoint locations
Your API will then apply authorization rules based on claims and scopes
OAuth is an authorization framework. Before OpenID Connect, some organizations were increasingly using OAuth as an authentication mechanism just as you stated in your question. While this is technically possible, it is rife with inconsistencies between one implementation to the next. The standardization of this method came around with OpenID Connect, where this group of vendors essentially said let's come up with a standardized approach to what we have been doing. The benefits of a standardized approach is collaboration, security, etc. The openid scope of OAuth was born.
Is SAML an authentication mechansim. ? I have seen this being written in many places.
As per my understanding SAML is not an authentication mechanism but a way to exchange authentication and authorization data between a service provider and an identity provider. ?
Both Service provider and identity provider have to be SAML compliant or basically understand SAML to take part.
Authentication can be done by any means like oAuth, Form etc. and then SAML exchange happens.
Best Regards,
Saurav
Actually SAML is a internet standards based technology to achieve web-based single on.
The actual authentication, which happens at the SAML IdP is out of scope of the specification.
However sometimes implementors do no accurately distinguish between SSO and authentication.
Chapter 1 from SAML Technical Overview, a document published in 2008 and still a good read:
The Security Assertion Markup Language (SAML) standard defines a
framework for exchanging security information between online business
partners.
...and then Chapter 4 in the same doc
SAML consists of building-block components that, when put together,
allow a number of use cases to be supported. The components
primarily permit transfer of identity, authentication, attribute, and
authorization information between autonomous organizations that have
an established trust relationship
SAML (Security Assertion Markup Language) is an identity federation protocol.
(1) Traditionally a web application utilizes a local data storage (such as MySQL which is used to store username/password credentials) to accomplish the login authentication.
On the other hand, a web application can leverage a third-party SAML Identity Provider (IdP) to accomplish the login authentication if the web application has been integrated with a SAML Service Provider (SP).
(2) Usually a SAML IdP utilizes identity repository (such as OpenLDAP) to provide identity authentication for a SAML SP-enabled web application.
(3) A web application, which has been integrated with a SAML SP, outsources login authentication to a SAML IdP.
Without loss of generality, we assume that the SAML IdP has been configured with OpenLDAP.
A typical SAMP SP-intitiated authentication procedure can be described below.
(I) A user launches a web browser to access a SAML SP-enabled web application.
(II) The user is redirected to a SAML IdP which will prompt username/password login screen.
SAML SP sends a SAML request to SAML IdP.
(III) The user submits the username/password credential.
(IV) The SAML IdP leverages OpenLDAP to validate the username/password credential.
(V) The user is redirected back and logged in to the web application if the user has been authenticated by OpenLDAP successfully.
SAML IdP sends a SAML response token to federate the user identity (such as username) to SAML SP-enabled web application.
(4) How to build and run Shibboleth SAML IdP and SP using Docker container demonstrates how a SAML IdP utilizes OpenLDAP to provide identity authentication and then federates the user identity (such as username) to a SAML SP-enabled web application, thus accomplishing the login authentication for the web application.
I am a beginner for saml authentication. I can understand the concepts and theme. But in real time, I do not know how to implement and code it.
What are all needed? How to code for the saml authentication? What technology needed? How many servers/websites needed? Which will be the service provider and identity provider. I do not know the procedure to code.
What are the prerequisites should i know?
I referred http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#1.Introduction|outline. But it is quite confusing. I could not get a clear idea to implement for my own.
What are the series of instructions to implement SAML authentication
for my own sever/website?
Which will be the IDENTITY provider(Authorization server) and
SERVICE provider?
How websites put it in service provider(Resource server) and saml authentication given?
How credentials stored and token response generated in the identity
provider.
How to implement as a code and what are needed to create?
Please help me.. Thanks in advance...
You haven't specified the language but on the client side, you need a SAML stack.
Refer SAML : SAML connectivity / toolkit.
On the server side, you need an IDP.
This could be ADFS, shibboleth, identityserver or an IDaaS product like Auth0 or Okta.
When reading about REST APIs and security, you invariably see OAuth 2.0 as the authentication panacea. But actually diving into the specs, true OAuth 2.0 requires service and authentication providers be separate, primarily so the authentication provider can be used for multiple services. Also clients are untrusted and not given credentials. OAuth seems an overly convoluted if your service and auth provider are the same.
On top of that many APIs just use some sort of client id/client secret into bearer token flow. Which is no better than username/password into session.
You split between Auth[-Provider] and Service-Provider, but actually there are 3 pieces involved:
Authentication.
Service Provider.
Service Consumer.
It is very common that Authentication and Service Provider are done by the same party.
It depends on the service consumer, if you need OAuth or not. In case you want 3-rd party applications to consume your services ON BEHALF of your users, OAuth is very useful.
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