Our requirement is to set up auth through ADFS.
The IdentityServer is for logging in.
We need the ADFS because we a SharePoint and we have multiple Claim Providers.
What we try to do:
SPA <--> ADFS <--> IdentityServer
URLS
SPA: https://example.com/app
ADFS: http://fedsrv.example.com/adfs
ID: https://idp.example.com/spa
ADFS
In ADFS we set up an application Group: OIDC_SPA with a native application Portal and a Web API Portal.
The native app does have a client ID: example and a redirect URI:
https://example.com/app
The Web API does have a Relying party identifiers: example,
has Permit everyone policy
and a transform rule PT all : x:[] => issue(claim = x);
and Client Permission allatclaims, opened and profile
The Claims Provider Trust is configured as following:
CP Federation metadata URL: https://idp.example.com/spa/wsfed/FederationMetadata/2007-06/FederationMetadata.xml
The CP identifier is https://idp.example.com/spa
WS-Fed Passive Endpoints is: https://idp.example.com/spa/wsfed
we also set the AnchorClaimType:
set-adfsclaimsprovidertrust -targetidentifier https://idp.example.com/spa -AnchorClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
and for home realm mapping:
Set-AdfsWebApiApplication -TargetName OIDC_SPA -ClaimsProviderName "<CP name>"
IdentityServer
We added a client with ClientID http://fedsrv.example.com/adfs/services/trust
ProtocolTyp: wsfed
RelyingParties:
| Field | Value |
|--------------------------|--------|
| Realm | http://fedsrv.example.com/adfs/services/trust |
| TokenType | urn:oasis:names:tc:SAML:2.0:assertion |
| SignatureAlgorithm | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| DigestAlgorithm | http://www.w3.org/2001/04/xmlenc#sha256 |
| SamlNameIdentifierFormat | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified |
IdentityResources
There is opened and profile configured.
did we forget something or did we configure something wrong?
the problem was, that the claims were not correctly mapped in the Application Group and Claims Provider trust.
Related
I have a basic Azure AD App Registration. This is a non-interactive client IE console/machine client with a secret and no redirect URI. I would also like this to also work for interactive clients however.
How can I add a claim to my token called "hello": "world"?
To add a custom claim like "hello": "world" in the token, you can create claim mapping policy using PowerShell.
1)Make sure to have AzureADPreview module installed, before running below commands.
Connect-AzureAD
New-AzureADPolicy -Definition #('
{
"ClaimsMappingPolicy":
{
"Version":1,"IncludeBasicClaimSet":"true",
"ClaimsSchema": [{"Source":"user","ID":"extensionattribute1","SamlClaimType":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/hello","JwtClaimType":"hello"}]
}
}') -DisplayName "HelloExtraClaim" -Type "ClaimsMappingPolicy"
Output:
2)Note the ID of the policy and assign it to your service principal using below command:
Add-AzureADServicePrincipalPolicy -Id serviceprincipal_ObjectID -RefObjectId policy_ID
3)To confirm whether the policy is assigned or not, run below command:
Get-AzureADServicePrincipalPolicy -Id serviceprincipal_ObjectID
Output:
4)To assign value to that claim, sign in as admin to Microsoft Graph Explorer and run the below query:
PATCH https://graph.microsoft.com/beta/me
{
"onPremisesExtensionAttributes":
{
"extensionAttribute1": "world"
}
}
Response:
5)Make sure to set "acceptMappedClaims": true in App's Manifest like below:
Go to Azure Portal -> Azure Active Directory -> App registrations -> Your App -> Manifest
6)Go to Expose an API tab and set Application ID URI to your domain like below:
7)Generate a token to your application by signing with admin account.
After decoding the above ID token in jwt.ms, I got the claim "hello": "world" successfully as below:
Credits: How to add custom user defined claims to azure ad token | GitHub by TiagoBrenck
I'm using ReactJs on the frontend, I just tried to generate a cloudfront signed url through AWS.CLOUDFRONT.SIGNER class using getSignedUrl() method, but it says "createSign is not implemented in the browser".
Please tell me if this is the right approach to do so, I want to stream a video from Aws in my React app, Thanks.
The createSign is not implemented in the browser is correct. This is an operation that requires authentication, so if your credentials (such as your access key) is in your web application, then that key will be exposed to any client that loads the page.
You should create a back-end service that conceals this key, and then expose endpoints on that service to create and return the signed URL.
See this similar question and answer.
(client) (backend service) (aws)
| POST /create-signed-url | |
|===============================>>| |
| | aws-sdk getSignedUrl() |
| |=========================>>|
| | |
| | new signed url |
| |<<=========================|
| signed url | |
|<<===============================| |
| | |
Azure AD Premium has the concept of Conditional Access Policies. When you change the sign-in frequency it doesn't affect the access token or refresh token lifetime.
Since the access token has a default lifetime of 1 hour, no matter what you set the sign-in frequency to in Azure, after 1 hour the refresh token will be used to fetch a new access token.
So setting a sign-in frequency in Azure AD premium has no effect on a default msal app.
And indeed I tested this by doing the following simple steps:
Download the msal angular sample that uses auth code flow with PKCE (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular)
Add an Conditional Access Policy in Azure AD premium on the app registration for the app above
Make sure the policy is applied when the user signs in (e.g. by checking Sign Ins blade or what-if tool on Enterprise app).
Below is the conditional access policy:
Below tenant configuration shows that the user cannot select the "Stay signed in?" option when signing into any application in this tenant.
Below the relevant parts of the results of dsregcmd /status. I am aware the SSO status has an effect on Conditional Access Policies.
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : <redacted>
Device Name : <redacted>
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : YES
NgcKeyId : <redacted>
CanReset : NO
WorkplaceJoined : YES
WorkAccountCount : 2
WamDefaultSet : NO
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
I obtained the following response from Microsoft server team and I can confirm that it is accurate, albeit unintuitive:
Conditional access executes based on token audiences, and we don’t
execute it for id_tokens where the token audience is a public client.
That’s why the CA policy doesn’t kick in
The reason why CA doesn’t execute for id_token for public clients is
because CA is meant to protect data from the cloud, and having an
id_token from a public client doesn’t grant access to any data from
the cloud.
It’s about the data that could be accessed in their request.
They can try few other options:
They can change their policy to apply to “All apps”, then SIF (Sign In
Frequency) will kick in. E.g. They can try to set the policy on
Exchange Online, and request mail.read scope Another example: They can
try to set the policy for Sharepoint Online, and request files.read
scope
So, we will apply the conditional access policy if the conditions are
met, but only for tokens that could access data in the cloud.
I changed the conditional access policy to apply to "all apps" instead of just the app registration for the msal app. The MSAL app does correctly reject the refresh token and redirect after 1 hour. I did not try the other examples, but they also seem like valid workarounds given what would trigger the SIF to kick in.
I'm trying to create a platform using angularjs (web), ionic (mobile) and expressjs (backend), the communication through REST. Angular and Node has differents servers.
.-----------. .----------. .-----------.
| SERVER A | | | | SERVER B |
| ANGULAR | <--> | REST | <--> | NODE |
| PORT 3300 | | | | PORT 3000 |
'-----------' '----------' '-----------'
The problem for me, is how to integrate socket.io in angular (or ionic) to communicate with the backend (for the chat part).
All examples that i see, they return an html page in the response. for example:
app.get('/', function(req, res){
res.sendfile('index.html');
});
What I want exactly, is how to send a messages from front to backend (for example to localhost:3000/users/chat knowing that i'm runing my angular project on localhost:3300), how to handle that messages from server, and how to response to them using socket.io
I mean to say how the flow should be between my client and server and github server. Starting in OAuth only I am not getting it and also I am stuck in an error for making get request. From where should I make the get request, client or server for OAuth. What is a better practice?
First take a look at this diagram (Made by me with draw.io).
Diagram explained:
As you can see there is no reference to MEAN stack in this diagram because this doesn't have anything to do with language preferences you choose.
Your client could be Angularjs | jQuery | ReactJS | ember | knockout | backbone | iOS |
Android| ....
Your server could be : node.js | php | python | java | ruby|.... .
Your database could be : mongodb | mysql | postgresql | couchdb|....
Understanding OAuth API:
OAuth API allow users to simply login from one app to another with the same credentials based on one place.
Furthermore it allows Single Sign On easily on different client apps.
The basic behind OAuth relies on one sign up and many log-ins.
Couple years ago, when you wanted to login to an app or a service you would have to sign-up.
then if you wanted login to a different service you would have to sign up again with obviously the same details ( Email, Birthdate, Username, Password, Photo, Gender... ) just to a different service.
That is madness, and made us as users impatient, writing those details every single time.
That was long time ago and now:
You sign up once to Facebook | Google Plus | GitHub | Twitter , and you can simply login to a different app or a service with those credentials powered by those companies, in return those companies will supply you as a software provider those details ( Email, Photo, Gender, Username, Friends, Followers ) which is a lot of data in less effort for the user himself.
After you have basic understanding of OAuth: Lets move on to the FLOW:
I'm going to write the flow by phases:
First Action:
User opens your app.
Second Action:
User can pick log-in with GitHub | Most likely you would also offer him to sign-up with his email.
Third Action:
User picks github login -> a popup by github is opened.
Three possibilities:
A) User has an account and logged in.
-> Simply press accept, GitHub returns a callback with Access Token, and generic data about the user.
B) User has an account and not logged in.
-> Simply enters login credentials (Email | Username & Password) -> Phase A.
C) User doesn't have an account.
-> User sign up to Git Hub -> Phase B -> Phase A.
Now: you have couple of actions needs to be taken:
In GitHub you have to supply information about -> Successful Login Redirect.
That means: URL to redirect after successful login.
When you fill that url in the settings, after the user has logged in, he will be automatically be redirected to that URL and with that request will be sent his details.
As soon as you get the details from GitHub API, you would want to save the user into the database on your server.
Why?
So the actions made by the user on your app will be saved.
Basically, I save everything: Data and Access Token.
Why do I need access token?
If you ever wanted to make actions on his GitHub profile, for example fork new repos, or follow other members, you would have to use this access token.
If I left anything unclear, I'd be more than happy to explain more.
#linial