I am developing a web application using EC2 on AWS.
In this application my client is requesting to use his SSO (Single Sign On) so I can verify the user against his Active Directory. My problem is that I can't get to know where to begin with, these are some of my questions:
1) Is this SSO takes place on my code or on my server?
2) Do I have to make different configuration for differents deployment environments (for example aws, azure, digitalocean, etc)?
3) Where do I define, send and parse SAML 2.0 format?
4) Do I have the send a POST request to the server where the SSO is installed? Or how is it managed?
So far I have found this tutorial, but I am still do not know what to do first, so any step by step information will help a lot.
First you need the client (Identity Provider IdP) SAML2 metadata. This will have their SSO endpoint URL and their X509 signing certificate.
Then you send them your SAML2 metadata with your Attribute Consumer Service (ACS) URL and X509 signing certificate.
Sample metadata here. Or you can build it here.
The certificates are normally long lived self signed certificates. They can be self signed as each side has a copy of the other's certificate which they will use to verify the signed request and response.
You construct a SAMLRequest and POST it to their SSO URL. There's an example request here.
They display their login page to the user and the user authenticates at their end.
They gather attributes for the user from their Active Directory and turn them into SAML attributes and put them in a SAMLResponse.
They POST the SAMLResponse to your ACS URL. There's an example response here.
You verify the signature on their SAMLResponse using their X509 certificate from their SAML2 metadata.
You extract the SAML Attributes from their verified SAMLResponse and take appropriate action in your application, e.g. create the user an account, perhaps their email address is one of their attributes.
The above is called the SAML2 Web Browser SSO Profile, explained here.
Depending on your stack, you can use something like:
Shibboleth (middleware, install on your server, it interrupts requests to specific paths requiring Authn against the Identity Provider [ADFS], and returns the user after successful auth setting some attributes telling you info about the user such as username, etc.). Works best if you can compartmentalize secured content into a particular path on the site like /secure.
SimpleSAMLphp (protect PHP resources directly)
Commercial SAML (ComponentSpace, etc. - works well if .Net app)
Basically, find something for your stack. DO NOT TRY TO ROLL YOUR OWN SAML IMPLEMENTATION!
Related
I'm not an expert but seems like one of the OpenID requirements is to have a /.well-known/openid-configuration endpoint.
Seems like Cognito is implementing this well as long as you don't use custom domain, e.g. point your browser to the URL below and you get a properly defined openid config JSON.
https://cognito-idp.{your region}.amazonaws.com/{your pool ID}/.well-known/openid-configuration
Now, if you use a custom domain try pointing your browser to the URL below, and you will see there is nothing but an error message:
https://{your poolname}.auth.us-east-2.amazoncognito.com/.well-known/openid-configuration
This is an issue because other apps/framework/library that rely on OpenID standards fail when trying to connect to a Cognito user pool.
Am I missing something?
Adding a custom domain doesn't change the issuer (iss claim in your tokens) and therefore the discovery URI is unchanged.
Your configured domain will be properly reflected in the configuration document (/.well-known/openid-configuration) and clients supporting discovery will be configured with your custom endpoints (authorization, userinfo and token).
I'm attempting to use Postman to "Get User Access Token" with Microsoft Graph API; however, my org recently enabled multi-factor auth and this call is now failing, stating:
"error": "invalid_grant",
"error_description": "AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access...
The Microsoft documentation for MS Graph API using Postman is very well written, but it is missing clear instructions how to pass in this second factor to the request.
The error points to https://login.microsoftonline.com/error?code=50076, but this just gives the same info.
I have the MS authenticator app which gives me this key/second factor; however, I don't know how to add this into the body/headers. I'm trying to find the specific key name for passing in the additional security token (I've tried things like 'token,' 'pcToken,' 'key,' etc.)
.
I was in the same predicament so here is what I did to solve it:
Firstly, I got the information from:
https://github.com/microsoftgraph/microsoftgraph-postman-collections/issues/4
You will need to use the OAuth 2.0 authorisation in Postman. Using the same GET request, go to Authorization -> Change the type to 'OAuth 2.0' then click 'Get New Access Token'.
From there, you can input your own details:
(replace [TenantID] with your own)
Callback URL: The redirect URL you stated in your app authentication.
Auth URL:
https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/authorize
Access Token URL: https://login.microsoftonline.com/[TenantID]/oauth2/v2.0/token
Client ID: You're application's ID.
Client Secret: You're Applications secret that you set under the 'Certificates & secrets' section.
Screenshot
Username Password Authentication is not supported for MFA because MFA requires interaction. But there is no interaction if you need to use Username Password Authentication to sign in.
See Username Password Authentication：
users who need to do MFA won't be able to sign-in (as there is no
interaction)
The answers above do not describe anything related to MFA by-passing via code.
MFA auth you need to use broker authentication where MS Authenticator app behaves as a broker.
If you integrate the proper libraries (ADAL, MSAL) your code will be able to interact with broker properly.
On Android and iOS, brokers enable:
Single Sign On (SSO). Your users won't need to sign-in to each
application
Device identification (by accessing the device
certificate which was created on the device when it was workplace
joined). We use Intune-managed devices for this purpose.
Application identification verification (is it really outlook which
calls me?). The way it works is when an application calls the broker,
it passes its redirect url, and the broker verifies it:
On iOS, the redirect URL is, for instance, ms-word://com.msft.com, the broker
parses and gets the appId (after the //) and verifies it's the same
as the appId of the calling app, which it knows (by the OS).
On Android the redirect URLs have the following form msauth://com.msft.word/.
To enable one of these features, the application developers need to set the UseBroker Boolean to true in the platform parameters. They also need to implement a delegate to react to the broker calling back the application as described in Platform parameters properties specific to brokers on Android and iOS.
Please refer to the MS docs for broker auth examples:
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-use-brokers-with-xamarin-apps
https://learn.microsoft.com/en-us/azure/active-directory/develop/brokered-auth
Is there a way to authenticate the Microsoft or google OAuth token in active directory without using an authentication server?
Here is the scenario:
A client app gets an Microsoft access_token from some external service.
Client app will make a call to some secured web API and pass that access_token along with the request header
If the access_token passed by client is valid then API will provide response to the client.
Is there a way to validate that access_token on API side?
My normal understanding about OAuth 2.0 is there needs to be an authentication server to which both the client and API would talk to as shown in the figure below:
But if the token is provided by some external service, Can we use it to validate our web API. Are there any ways to implement such authentication?
You can learn more about AAD Signing Keys and handling Key Rollover using this page: Signing key rollover in Azure Active Directory
Validation of the token, once you have the signing key, can be done using existing libraries like OWIN. You can also try following instructions like this (although it seems the document isn't 100% complete yet): Manually validating a JWT access token in a web API
This library is also available, but I think OWIN is supposed to have replaced it in general.
Also check out this blog post, which has a pretty great deep dive into token validation.
Django Oauth Toolkit docs don't describe the redirect uris, authorization grant type, or client type fields when registering your application.
The tutorial says to set client type to confidential, grant type to password, and leave uris blank.
What do the other options do?
e.g. What is client type public vs confidential? What do the grant type password, credentials, authorization, implicit do? And what are the redirect uris for?
I have found sparse information about them but no actual explanations as they pertain to django rest framework and django oauth toolkit.
You'll get answer to all your questions once you read about Oauth2 Protocol from here
But I'll try to answer your questions in brief:
I'll be using the words client and Resource Server frequently. In Oauth2 protocol, client means the system which accesses resources, data or service. (It could be your mobile app or javascript app consuming REST API's of your API Backend (or Resource Server) . If you have implemented Facebook login in your mobile/JS apps, chances are, your API backend requests Facebook for user's information. In that case your API backend is being a client and Facebook is Resource Server)
Client Types:
Client type is either confidential or public depending on whether that client can keep it's client_secret a secret. (For example, an AngularJS app cannot keep it's client_secret hidden, since anyone can do "Inspect Element" in a browser and search for it, so such a client has to be registered as public.)
Authorization Grant Types:
There are four kinds of Authorization Grant Types in Oauth2 protocol.
Authorization Code:
In this grant type, the client requests for an authorization code first, then exchanges that authorization code for an access token. It's a two step procedure. Use this if the client is an outsider (more on it in Resource-owner password based).
Implicit:
Usually used along with public client_type. Instead of a two-step procedure above, the client gets access token in one go.
Resource-owner password based:
This is used when there is a high degree of trust between client and Resource Server. This is the case between your API backend and your Mobile app. (There is high degree of trust between your API backend and Javascript app too, but since it cannot keep it's client_secret a secret, you have to use Implicit Grant type with it). Facebook or Google etc. will never give you this kind of Authorization Grant because, for them, your API backend is an outsider.
Client Credentials:
It is least commonly used. Please read about it in above mentioned document.
Redirect URI's:
Now, as far as Redirect URI's are concerned, they are needed only in Authorization Code or Implicit grant types (Not sure about Client Credentials one, somebody please enlighten me on this in comments).
Redirect URI is given so that the Resource Server knows where to send the access token. Imagine if you are implementing Facebook login. In that case you will go to developers.facebook.com and register your application (like you did with django-oauth-toolkit), while registering your application, you will specify a Redirect URI.
Specifying a Redirect URI is a way of saying. "Hey Facebook, send the access token on this URI". So if you set Redirect URI something like https://your_domain_name.com/token/facebook/, Facebook will redirect to your specified Redirect URI at the end of Oauth2 process and give Access Token in the form of GET parameter, like https://your_domain_name.com/token/facebook/?token=some_long_string&some=other_parameters.
Could you please explain why the WSO2 Travelocity test application requests a "Domain Name" input field in the sign-in screen, when the WSO2 is configured to use, beside basic auth, also a federated authentication mode (WS Release 5.1 - Advanced Configuration). What is the reason to request the domain name part, as for external authentication, for example by use of SAML protocol, I expect to see a redirect onto the external IdP login screen. Apparently the Login redirect is rejected due to this missing input field at the Domain Name. Is there a sample configuration and use case available for setup of outgoing IdP federation?
Further Details from Testings
I've updated the IdP configuration following the WSo2 setting which describes the federation effort with help of Shibboleth products (see below). After this change now I see a login screen from the external IdP ("zee") as well as an interchange of messages between the browser and the external IdP. I also see a SAML POST message in the SSO protocol tracer plugin of the Browser, displaying a long list of claim assertion data, which signals that Login was successfully processed, returning the profile data of my account.
At the Travelocity service provider (SP), now I see the following error message at the screen:
"The entity name must immediately follow the '&' in the entity reference."
I've validated the SAML feedback data and its XML format consistency using an online XML validator, which passed successfully for SAML response XSD format. Such type of XML parser errors are often caused by use of special characters, but its not the case at the current assertions and tests.
The issue happens inside the Travelocity which has difficulties to read the SAML assertion data.
Suggestions from the community how to parse the SAML feedback data using the Travelocity tool, are welcome.
Refer https://docs.wso2.com/display/IS510/Configuring+Single+Sign-On for configuring Basic scenario with travelocity app
To configure federated authenticators:
https://docs.wso2.com/display/IS510/Federated+Authentication
For Advanced Configuration with Multiple Authenticators
https://docs.wso2.com/display/IS510/Configuring+Local+and+Outbound+Authentication+for+a+Service+Provider
Refer https://docs.wso2.com/display/IS510/How+To%3A+Configure+Shibboleth+IdP+as+a+Trusted+Identity+Provider as an example use case.
It seems that you have custom authentication since you have domain name filed at the login prompt.