My application is receiving attributes for SSO Provisioning that are correctly packaged in xml and are in a SAML Response and have correct values but overlong and unfriendly names.
Example:
AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
AttributeValue="fred.bloggs#enterprise.COM"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
AttributeValue="Fred Bloggs"
What advice can I give to the ADFS admin to help get user friendly name, please?
For example "emailaddress" instead of
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
In the .NET world the ClaimType Class is your friend, so you don't have to deal with the actual URI.
Related
I want to get the user emails used for Azure organization on callback action of SSO web login flow.
Could you please advise which property and which API permission should I request for it? I tried upn, preferred_username, and email properties, but as I understand they can differ from the actual email.
Tried multitenant and single-tenant approaches.
Keep in mind that the user logs in with their UPN, which is typically (but isn't necessarily) the same as their email address.
The email claim should contain the user's email address if the directory is looked after by admins. That's the one you're after.
More information on the default claim set can be found here.
More information on how the UPN might be populated, including the approach of using an Alternate ID can be found here.
I don't have admin access to the top-level of my company's OneLogin system. However, if I tell our IT people to create a particular type of "SAML Test Connector", they will do it and will give me admin access for just that application. Then I can set it up as I wish.
What I am after is SP-initiated SSO, with the resulting assertion containing the authenticated user's email address as its subject, and with the assertion containing some additional attributes about the user.
The list of SAML Test Connectors is somewhat confusing, and I have some questions about it.
Q1) "Test" connector? Are these connectors only for tests? Or should I read "test connector" as "custom connector"?
Q2) When a connector is indicated as being "(IdP)" or "(SP)", do this mean "IdP-initiated SSO" and "SP-initiated SSO"? I'm guessing that it does, but it would be nice not to have to guess.
Q3) The one connector that I actually want, that you would probably describe as "SAML Test Connector (SP w/attr)" isn't actually present! Does OneLogin support it?
Q4) For attaining SP-initiated SSO with the assertion containing attributes (i.e. what I actually want), what app type do I tell our IT guys to create?
I'm guessing (but again it would be nice not to) that if they created "SAML Test Connector (SP)" then I could tinker with that, and add attributes via the app's configuration. Correct?
(BTW: I don't need the assertion to be encrypted, and I don't need the response element rather than the assertion element to be signed.)
Thanks in advance.
Q1) Read as "custom connector"
Q2) Yes, when it includes SP you will see that in the "Configuration" tab there is a SP Login URL. That URL will be used to redirect the user there when clicking on the app icon of the dashboard. (It will start a SP-initiaited flow at the IdP, instead of drectly send a SAMLResponse).
Q3) The "SAML Test Connector (SP)" includes attrs
Q4) "SAML Test Connector (SP)"
I have always only used "OneLogin SAML Test (IdP w/ multi value attr)". You can configure it to your needs.
We have a multi-clients (internally identified as "corporates"), web-based software, in which we have implemented SSO via SAML 2.0. Each client is a Corporate, and each Corporate has its own users.
At the moment, the users are identified by the NameId property of the SAML response (matching the Username field in our application), and the value of the Issuer field allows us to know which Corporate the user is from.
Now, one of our big client has white-labelled the solution, and is using it in-house, with a single Identity Provider for all of its own clients. This mean there is a unique Issuer value for all SAML messages, and we can no longer rely on that to identify the user's Corporate. Fortunately, their SAML message gives all the information we need, formatted this way:
The NameId value is formatted as "corporate:username"
There is a specific "companyId" Attribute, with value "corporate"
There is a specific "operatorId" Attribute, with value "username"
I guess that identifying the Corporate is then straightforward : we need to check the value of the custom "companyId Attribute and compare that with the Corporate name. Easy.
But what about the username? Is it safe, or does it follow best practices, to check the "operatorId" Attribute instead of the NameID property ? Or should we in all cases always rely on NameId, and therefore put a custom parsing logic in place to extract the corporate and username from the NameId ?
How would you do that? I'm not able to find a similar case.
Thanks!
It doesn't seem to follow your company best practices :), but as soon you have validated the request is all up you and what you agree with your customer. It will be thought harder to maintain because it is an exception.
I have a nodejs project that is using adal-node (https://www.npmjs.com/package/adal-node) to authenticate via OAuth2 to Dynamics CRM. I have successfully gotten the authorizationUrl, then posted the code to get the accessToken. However, this last response does not return an instanceUrl. So I've been scowering the MSDN pages online for documentation on how to use the accessToken to obtain the correct organization instance Uri. I've tried this (https://msdn.microsoft.com/en-us/library/mt607485.aspx) and just get a 401 "Authorization has been denied for this request" response. Maybe I'm formatting this request improperly? Can someone kindly direct me to some documentation on how to use the valid accessToken I've obtained to retrieve the organization instance Uri for this user? Thanks.
Recently went through this myself, the issue I think you might be experiencing is the resource that is being requested access to when you request your authentication token is incorrect. While you would think it would be https://globaldisco.crm.dynamics.com/, I actually been successfully with https://disco.crm.dynamics.com/ (ensure to include the trialing slash) as the resource.
If your token is rejected then look at the WWW-Authenticate attribute in the response header and it will indicate the resource you should be requesting. Similar to this:
Bearer authorization_uri=https://login.windows.net/common/oauth2/authorize, resource_id=https://disco.crm3.dynamics.com/
After getting the right resource I was able to query the global disco service without issues and even though giving the NA disco resource returned instances from various regions. This worked on Azure AD tenants started in NA as well as the UK.
I have blogged a full sample here - http://colinvermander.com/2017/01/19/calling-the-dynamics-global-discovery-service/
According the description at https://msdn.microsoft.com/en-us/library/mt607485.aspx, to request against to https://globaldisco.crm.dynamics.com/api/discovery/v1.0/Instances(UniqueName='myorg'), you need to replace myorg to your own unique name of your dynamic crm server.
You can refer to https://www.dynamics-pros.com/support/kb/kb102033 for how to get the unique name.
I need a user who has access to a lead record, but does not have access to the contact connected with the lead, to be able to view certain contact info. So what I need to be able to do is somehow get around the fact that the user has no access to the underlying contact.
Impersonation seems to fit the bill but all I can find is info about how to impersonate in a plugin and silverlight.
What I'd like to be able to do is somehow impersonate using a HTML web resource on the lead form. Is this possible?
Although this is not recommended as it might pose security threats, and that I've never tried it before; you could try using the SOAP endpoint. I believe it wouldn't work with the REST endpoint.
Try using the following SOAP header, where you can put in the GUID of the user you want to impersonate:
<soap:Header>
<CrmAuthenticationToken xmlns="http://schemas.microsoft.com/crm/2007/WebServices">
<AuthenticationType xmlns="http://schemas.microsoft.com/crm/2007/CoreTypes">
0
</AuthenticationType>
<OrganizationName xmlns="http://schemas.microsoft.com/crm/2007/CoreTypes">
AdventureWorksCycle
</OrganizationName>
<CallerId xmlns="http://schemas.microsoft.com/crm/2007/CoreTypes">
00000000-0000-0000-0000-000000000000
</CallerId>
</CrmAuthenticationToken>
</soap:Header>
Check out this link for a possible solution - http://www.datazx.cn/Forums/en-US/cc172c24-0478-4016-9656-ccddffdd7988/action?threadDisplayName=crm4-javascript-impersonation&forum=crmdevelopment