Is it possible to gather the SignatureMethod from the IdP SAML metadata using ITfoxtec.Identity.Saml2? - itfoxtec-identity-saml2

Using ITfoxtec.Identity.Saml2 is it possible to gather the Saml2Configuration.SignatureAlgorithm property automatically via the metadata provided by the IdP?
See two examples below, the SignatureMethod is available but it doesn't appear to be referenced in the EntityDescriptor, which focuses on the EntityDescriptor.
Sha1 example
Sha256 example
Thanks

No. The signature algorithm is not exposed in the SMAL 2.0 metadata. You have to ask the IdP.

Related

Exchange API missing from Supported Legacy APIs

I am currently trying to follow the steps listed here:
https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth
However to add the delegated permission I need (EWS.AccessAsUser.All), the author suggests you should
"Select Add a permission. On the Request API permissions page, select Exchange under Supported legacy APIs."
This worked a few months back when I tried it in a prototype but the whole Exchange API under the "Legacy APIs" section appears to have been removed.
I can not find any mention of this anywhere on GitHub, SO or MSDN.
Please note some of the functionality I need is not yet supported in Microsoft Graph so using that API is not currently an option for me.
Any help would be appreciated.
I found out to my surprise that now you will need to search it within the "APIs my organization uses" by the name : Office 365 Exchange Online. You will be able to assign the necessary permission afterwards.

Best practise for populating access token with external claims

We have implemented IdSrv4 on top of AspNetCore Identity and we use ADFS as external IdP. From ADFS we wan´t to get the users AD-groups, upn and som other claims. The claims will be used both inside our IdSrv4 implementation, but will also be sent to our API-resources as part of the access token.
The current situation in our IdSrv4 implementation:
ADFS has been configured so that it emits the claims that we want and in our IdSrv4 implementation those claims are received as expected in the "ExternalLoginCallback" method of the AccountController.
IProfileService has been implemented in order to fill the "IssuedClaims" list with claims.
BUT, I haven't managed to build the connection between those to steps. What is the preferred way to preserve the claims received in "ExternalLoginCallback" and put them into the generated access_token in the IProfileService class?
Right now I have managed to get it working by saving the token using the method "UpdateExternalAuthenticationTokensAsync", which will save the token in the database. Then in the profile service I fetch the token and read the claims into the emitted token.
But this doesn't feel right and while searching for the proper way I´ve seen examples use the class IdentityServerUser that has "AdditionalClaims" property, but I can't find a way to plug that type into the event flow.
Also, when configuring the external IdP you have these "ClaimActions" that can be mapped, but I don't understand what they are.
Finally, I assume that the database tables "IdentityClaims" and "ClientClaims" with corresponding entities should be used for this purpose but I can´t figure out how. Or should they be saved in the "AspNetUserClaims" table to save the actual claim type/values and not only claim mappings?
So basically, there must be a best practice for this scenario that seem to avoid me and I would be greatful if someone could share it.
The main issue in my problem was that the problems I first encountered with persisting the Claims in the AspNetIdentity-Db led me to a wild goose chase.
Returning to this after a week or so made me give this another shot. Turns out that the DI injected "_userManager" wasn't "connected" to the current DI injected "_signInManager". If someone has an explanation for this, please share!
What did work was to use the "_signInManager.UserManager" to update Claims on the user. This properly stores the Claims in the "AspNetUserClaims" table, and can then be retrieved in the profile service.
UPDATE 1:
Of course there was a logical answer to that as well. A user manager is created by default even if you don't call "AddUserManager" on your identity setup during startup. BUT, in my case I have extended the IdentityUser class and now by doing it like this it all works as excpected (where "UserIdentity" is my derived class):
.AddIdentity<TUserIdentity, TUserIdentityRole>(options =>
{
options.User.RequireUniqueEmail = true;
})
.AddEntityFrameworkStores<TIdentityDbContext>()
.AddSignInManager<SignInManager<UserIdentity>>()
.AddUserManager<UserManager<UserIdentity>>()
.AddDefaultTokenProviders();

Microsoft Graph API - Azure AD Connect - extensionAttribute

When I try querying extensionAttribute with Graph API (Hybrid Exchange), I cannot get any value.
E.g., if I try: https://graph.microsoft.com/v1.0/users/<userid or upn>?$select=extensionAttribute2, I cannot see the value even I know it’s there.
Do you know how to get it properly (or a workaround)?
Thank you
Are these values synced to Azure Active Directory? All properties for the AAD User can be found in the Microsoft Graph API docs here : https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
It sounds like these are being synced from an AAD Connect environment, so it's most likely you are trying to get the onPremisesExtensionAttributes.
Per the description:
Contains extensionAttributes 1-15 for the user. Note that the individual extension attributes are neither selectable nor filterable. For an onPremisesSyncEnabled user, this set of properties is mastered on-premises and is read-only. For a cloud-only user (where onPremisesSyncEnabled is false), these properties may be set during creation or update.
I suggest taking a look more thoroughly through the documentation in regards to this. In addition to that, as you mentioned Exchange, note that the custom attributes from exchange are the same as the extension attributes. For more info on this see : https://github.com/microsoftgraph/microsoft-graph-docs/issues/5950
This is a separate sort of "Extension Attribute" but I figured I would include this in the answer as well. There is a different extensibility section for the Microsoft Graph, and the docs on this can be found here : https://learn.microsoft.com/en-us/graph/extensibility-overview
If you see information on these extensions, know that this is separate from the on-prem extensions.

Shibboleth custom password flow

I need to set up Shibboleth IdP to validate user name and password against a custom application.
Our application exposes a REST API to which one can pass a user's credentials and either returns a 401 on failure or a JSON object with some user metadata on success.
I was able to achieve this in SimpleSamlPHP IdP with a 30-line class, but having to switch to Shibboleth, I am having a hard time finding directions to do the same there.
Reading through the documentation the suggested solution seems to be to create a custom back end for the password login flow but the Wiki does not explain in detail how to do this.
Can somebody point me out to some tutorials or sample code on which files need to be created or changed in order to do this (even basic examples of checking against a credential file or database would be fine)?
You are looking for an [External Authentication Flow] (https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAuthnConfiguration)
For an example, see the shib-cas-authn3 project (https://github.com/Unicon/shib-cas-authn3). It uses the CAS Server to authenticate the users. It then creates an IdP session from information retrieved from CAS.

How to access the PARSE rest api?

I am using parse.com for the data side of my app. I am new to parse and angular, I was wondering how do i access my rest api, when i put the url in it asks for a username and password but which one?
Also is there a specific way to use the rest api?
You are looking for the REST API docs, which can be found here:
http://docs.parseplatform.org/rest/guide/
Go through the 'Getting Started' section, it lays out in excellent detail how to address the API and gives good examples.
Regarding the login/pass, Parse requires you to create a User object in order to use the REST API; it's asking you for a User so the DB knows what level of access you have to various objects. (Parse uses ACLs, access control lists, for user security. ACLs are your friend, learn them.)
Good luck in your new endeavor!

Resources