We're using an application that authenticates using Azure ACS with a Google ID. But the nameidentifier that we get from Google keeps changing. It appears that this is based on the IP address which fluctuates when using Azure. So I'd like to have the output claim type be something other than the nameidentifier.
However if I change the output claim type (in the Rule Group panel) for the input nameidentifier to emailaddress we get a server error when trying to authenticate: Sequence contains more than one element
Is there a trick to setting up the rule groups for Google so you get back a token that doesn't change all the time?
As you already suspected, the ID is unique per realm/domain, but this should be based on the ACS namespace, not the URL of your application.
Now, using emailaddress is much safer in case you might need to use a different ACS namespace or if you no longer want to use ACS at all. In order to map the emailaddress claim to the namidentifier (output claim), you'll need to delete the actual nameidentifier first:
Related
So I created an enterprise application and have it configured for SAML based SSO. As I understand it, I've configured it so that the Unique User Identifier (Name ID) should be set the the email of the user within Azure.
When I attempted to login to test or use my new application through the portal, I can see that the NameID value in the response is actually set to a random string of characters (zReN4-W7ufefDDEh4pJ19K7pcMV84O5RKHSeOQ6wArU) which I assume unique identifies my user. I've tries altering the source attribute of the Name ID as well as the name identifer format but it always comes back as the exact same string in the response.
The application I'm trying to log into requires that the name ID be set to the user's email address and I don't understand why it's not being shown that way in the response. Any ideas why this is happening?
The NameID value is a targeted identifier that is directed only to the service provider that is the audience for the token. It is persistent - it can be revoked, but is never reassigned. It is also opaque, in that it does not reveal anything about the user and cannot be used as an identifier for attribute queries.
Generally, if the user does not have value in mail attribute, then Azure AD would send persistent format for Name ID and set random value in it.
For more information on the SAML Protocol can go through this article and similar question
Im running a Azure Webapp with application insight.
I know Microsoft cant show the real IP (Client_IP) so I add the real IP address to all requests (Ip).
I have a visitor client_id="h9zbt" that in the last 24h is using 48 different client_IP adresses.
The same user also has several real IPv6 adresses.
I like to block this IP from my website, but I think this looks so strange.
Is it really the same user?
How is Application insight tracking the User_Id?
Image link
Usually application insights is automatically opening a session automatically for each user (look for the ai_session key). Therefore the default user scope would be a session scope.
You can override this behaviour by sending a user context if you have some kind of sign-in. (https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context)
I find it likely that it's the same user on the same device, just using several IP-addresses, maybe as an unsuccessful attempt to stay anonymous.
User IDs should persist across user sessions to track how users behave
over time. There are various approaches for persisting the ID.
A definition of a user that you already have in your service.
If the service has access to a browser, it can pass the browser a cookie with an ID in it. The ID will persist for as long as the cookie
remains in the user's browser.
If necessary, you can use a new ID each session, but the results about users will be limited. For example, you won't be able to see how
a user's behavior changes over time.
The ID should be a Guid or another string complex enough to identify
each user uniquely. For example, it could be a long random number.
If the ID contains personally identifying information about the user,
it is not an appropriate value to send to Application Insights as a
user ID. You can send such an ID as an authenticated user ID, but it
does not fulfill the user ID requirement for usage scenarios.
mentioned in Azure doc.
https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context
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 am experimenting with using the Access Control Service in Azure. I have most of it working, I can log in using any of the providers but I'm having an issue with the claims against the WindowsLive provider. With the google provider I am able to get such useful information as the person's name and their e-mail address. I put similar claims in for WindowsLive but I get back the same value for every single claim. I've tried
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (I expected this to be gobbildygook)
http://schemas.xmlsoap.org/claims/EmailAddress
http://schemas.xmlsoap.org/claims/CommonName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
each of these return something like :oULpbTv2AMylPasgUOsLZAHjaBYtxldrU+gg3aS5nI4=
Now I'm pretty sure that isn't my e-mail address because it wouldn't fit on my business card and I know it isn't my name because my mother isn't Welsh and wouldn't support me being named as if I were.
I followed the tutorials found at http://robbincremers.me/2012/02/22/using-windows-azure-access-control-service-to-provide-a-single-sign-on-experience-with-popular-identity-providers/ and http://msdn.microsoft.com/en-us/library/gg185914.aspx to get this set up.
Is there some way that I can get information other than an identifier out of WindowsLive? Maybe the issue is related to my not setting up an encryption certificate?
Edit: After some searching I found Are any other claims available from Windows Live ID via the ACS 2.0 identity provider? which suggests that my attempts to get more information out of WindowsLiveID is a hopeless quest. I will just prompt users for information when they log in for the first time.
The windows live provider doesn't give you anything other than a unique providerId. This is unique to your application and the user's windows live id. Google is a little better in that they give you the users name as well as their email.
The way I solved this is that on account creation in my application I just collect any information from the user that I need in addition to what is provided from the claims. So if they are using Google then i pre-populate their Email and name on my "Create Account" form. If they're using Windows then the form fields are just blank and they have to fill out the necessary info to finish creating their account. It works pretty well.
This question is a continuation from How to pass required claims to OpenID identity provider with Azure ACS?
Its a slightly different take on the problem though, thus I'm posting this as a new question. Note: I'm also cross-posting this to the Azure Security forum but so far haven't gotten any useful input.
The Azure ACS samples shows that it is possible to add arbitrary OpenID identity providers to ACS. But for ACS to actually be helpful in our project as an STS for various popular providers we set out to get ACS working with MyOpenID.com (again, also used in the samples). The problem, as also the good Vittorio shows, is that MyOpenID will not give us claims like name and email address unless asked for. Vittorio and others states that this is because MyOpenID doesn't support Attribute Exchange.
I'm not so sure about that, though. Digging a bit deeper into the request url that ACS generates I can see that parameters like openid.ns.ax=http://openid.net/srv/ax/1.0 and openid.ax.required=email,fullname,firstname,lastname. Also, openid.ax.type.email is typed to the axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand the axschema.org types and will thus not return an email value.
What I do know is that MyOpenID understands the schema.openid.net/contact/email type. So building on this I manually changed the ACS request url to use the openid.net schema instead of axschema. Lo and behold, MyOpenID reacts and shows that my email address in fact will be returned.
Here is a list of the parameters I'm trying to pass in to myopenid.com/server endpoint:
openid.ns=http://specs.openid.net/auth/2.0
openid.mode=checkid_setup
openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
openid.identity=http://specs.openid.net/auth/2.0/identifier_select
openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid...
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.required=email,fullname
openid.ax.type.email=http://schema.openid.net/contact/email
openid.ax.type.fullname=http://schema.openid.net/namePerson
Unfortunately, when the response is returned back to ACS it isn't good enough, and ACS fails with the following error codes:
HTTP Error Code: 400 Message: ACS30000: There was an error processing an OpenID sign-in response.
Inner Message: ACS90014: Missing required field 'openid.ax.value.email'.
Trace ID: f8e09e6f-0765-4370-9f03-f744cce6fa2a
Timestamp: 2011-08-02 17:12:57Z
I've tried adding additional fields without changing the original email type, but only get the same errors. I'm starting to suspect that it is in fact ACS that is not supporting AX to its full extent and that it is somewhat hardcoded to only accept claims of certain types.
The question is: does my request parameters look right to you or am I missing something obvious here?
NOTE: my initial setup is working, if I leave the ACS request unchanged and in ACS only configures a single Passthrough rule for the identity provider, I can successfully authenticate my website through ACS using the MyOpenID identity provider. The problem remains though that MyOpenID will not hand over e.g. FullName or Email to ACS if the request from ACS does not explicitly ask for the claim types http://schema.openid.net/namePerson or http://schema.openid.net/contact/email
For security reasons, ACS can't allow callers to retype the email address claim. Effectively, what you're unknowingly doing is attempting is a variant of attack 4.5 (OpenID Data Type Confusion) from this paper. For security reasons, ACS has to ensure that email address and the other AX claims it supports exactly match the types it is aware of, otherwise malicious callers could trick ACS and substitute one claim for another. It's not that ACS doesn't support AX, it's that ACS only supports a single claim type as the email claim, and it's not the same one MyOpenID uses. In short, this isn't going to work.