none
Using MyOpenID.com as Identity Provider

    Pergunta

  •  

    Update: cross-posted to StackOverflow to (hopefully) attract more eyeballs :)

    Hi,

    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 http://axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand (or don't want to :) the axschema.org types and will thus not return an email.

    What I do know is that MyOpenID understands the http://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.

    Unfortunately, when the response is returned back to ACS it isn't good enough. It 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 chaning the original email types, 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.

    I would really love to get some input on this. Azure ACS is such a compelling product for our software but at this point, not being able to integrate a relatively popular identity provider may be a showstopper for us.

     

     

     


    - Peter - http://kodecompagniet.com
    • Editado Peter Lillevold quinta-feira, 4 de agosto de 2011 13:41 added link to cross-post at SO
    quarta-feira, 3 de agosto de 2011 13:44

Todas as Respostas

  • Hi Peter,

    ACS currently supports only OpenID 2.0 Identity provider. From your NS, it looks like MyOpenID.com is of V1.0. For some basic checks, you can try with Yahoo or Google open id which is pre-configured in ACS 2.0. You can try the same through ACS lab too (http://www.azuresupport.com/2010/08/appfabric-access-control-service-adds-support-for-openid-facebook-liveid-google-id/).

    Thanks,

    Seetha

    -----------------------------------------------------------------------

    Please Mark as answered if this answers your query or Vote as Helpful if this answer helps you in resolving your problem

    quarta-feira, 3 de agosto de 2011 14:46
  • Hi Seetha,

    no, MyOpenID supports v2.0. The namespace I mentioned is the claims type namespace we're using, in this case Attribute Exchange 1.0.  The openid ns namespace parameter openid.ns is generated with the value http://specs.openid.net/auth/2.0, which MyOpenID seems to accept.

    In fact, 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.


    - Peter - http://kodecompagniet.com
    • Editado Peter Lillevold quinta-feira, 4 de agosto de 2011 12:12 cleaned out some html
    • Sugerido como Resposta NanaNancyNeuhaus domingo, 29 de abril de 2012 16:18
    quarta-feira, 3 de agosto de 2011 21:31
  • Oh.. ok. Got it wrongly as 1.0. Sorry Peter, I could not think of a reason for this problem or workaroud/solution. I will keep watching this thread for any solution to your problem.

    -Seetha

    quinta-feira, 4 de agosto de 2011 08:53
  • Hi Peter,

    As you have already know, ACS uses the OpenID Attribute Exchange Extension to retrieve OpenID user attributes while MyOpenID doesn't support Attribute Exchange. Although you can modify ACS request url to use the openid.net schema instead of axschema, the response from MyOpenID is not valid to ACS. For email address, ACS expects attribute http://axschema.org/contact/email returned by the identity provider. But MyOpenID will not return this. This causes the problem. You can collect Fiddler trace to verify this.

    Thanks,

    Carson


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    sexta-feira, 5 de agosto de 2011 07:06
  • Hi Carson!

    It seems wrong to state that MyOpenID doesn't support AX, because I can successfully retrieve other claim types from them using the same AX protocol as ACS generates. The only difference is in the claim type uris. So to be precise, MyOpenID does support Attribute Exchange. What it does not support is the axschema attribute types. 

    From my testing I have these three scenarios:

    1. Given a request for the axschema.org email, MyOpenID will authenticate the user but does not return any claim values.
      ACS accepts the response, redirects to the RP, and all is well except that we didn't get any data from MyOpenID apart from the user identifier.
    2. Given a request for the schema.openid.org email, MyOpenID will authenticate the user and return the email value (if configured on the chosen OpenID persona). 
      ACS fails at the response with error ACS90014 "Missing required field openid.ax.value.email"
    3. Given a request for the axschema.org email and an additional required attribute asking for e.g. the schema.openid.org email or name types, MyOpenID will authenticate the user and return the email or name value (if configured on the chosen OpenID persona).
      ACS fails at the response with error ACS90014 "Missing required field openid.ax.value.email"

    To me it seems that it is actually the ACS implementation that have a problem. Case 3) should be enough proof of that. Why does it fail in 3) when it succeeds in 1) ? Clearly ACS doesn't implement handling the AX response properly or else it should be happily accepting the missing email as in 1), or even better: picking up the other values supplied from MyOpenID. Stating that it fails because the email attribute is required doesn't make sense. ACS clearly doesn't mind the missing email in case 1). 

    After my last testing I realized that I could actually see in the url of the ACS error page what is returned from MyOpenID to ACS. Here is a breakdown of the request parameters received from case 3) when requesting the axschema.org/email and the openid.org/name (leaving out some of the encrypted stuff):

    • openid.ax.count.email=0
    • openid.ax.count.name=1
    • openid.ax.mode=fetch_response
    • openid.ax.type.email=http://axschema.org/contact/email
    • openid.ax.type.name=http://schema.openid.net/namePerson
    • openid.ax.value.name.1=John+Doe
    • openid.claimed_id=http://myaccount.myopenid.com
    • openid.identity=http://myaccount.myopenid.com
    • openid.mode=id_res
    • openid.ns=http://specs.openid.net/auth/2.0
    • openid.ns.ax=http://openid.net/srv/ax/1.0
    • openid.op_endpoint=http://www.myopenid.com/server
    This is still valid AX protocol. It is very frustrating that ACS doesn't work with this. It would've been such a good fit if ACS interpreted additional ax.value attributes and brought them into the rules engine as claims.


    - Peter - http://kodecompagniet.com
    sexta-feira, 5 de agosto de 2011 09:19
  • According to myOpenID’s XRDS document (https://www.myopenid.com/xrds), it does not support attribute exchange, instead supporting simple registration. If an identity provider support attribute exchange, the namespace "http://openid.net/srv/ax/1.0" SHOULD be listed as an <xrd:Type> child element of the <xrd:Service> element in the XRDS discovery document.


    ACS uses the attribute exchange extension to get name and email address from OpenID providers. As myOpenId doesn't support it, you will only be able to get the user’s identifier from myOpenID. This is what you see in scenario 1.

    If you look into the acs request url, email is required and the type is specified.

    openid.ax.required=email,fullname,firstname,lastname
    openid.ax.type.email=http://axschema.org/contact/email

    Even though you can modify the acs request url, you will see error if the response is not valid. The error message "ACS90014: Missing required field 'openid.ax.value.email'." means that the required email value is not returned to ACS.  From the response from MyOpenId to ACS, email value is not returned. You can have a try with an indentity provider that supports attribute exchange and compare the responses.

    This is not ACS's problem, All of these are OpenID Attribute Exchange standard. You can find the document at:
    http://openid.net/specs/openid-attribute-exchange-1_0.html

    Thanks,

    Carson


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    segunda-feira, 8 de agosto de 2011 07:40
  • Carson,

    thanks for the reply and putting up with my nagging. Just to clarify, I'm in no way associated with MyOpenID.

    So...

    I'm familiar with the Attribute Exchange standard, and yes, according to the spec the XRDS document should list the supported namespace. However, it is not required, and may according to the spec be omitted if there are valid reasons. Still, this is only used for service discovery, not for the actual claims exchange.

    Here's the two requests from scenario 1) and 2):


    1) http://www.myopenid.com/server?...
    &openid.ax.required=email&openid.ax.type.email=http://axschema.org/contact/email

    2) http://www.myopenid.com/server?...
    &openid.ax.required=email&openid.ax.type.email=http://schema.openid.net/contact/email 


    The only difference is in the type we're requesting. The AX spec does not dictate that email must be in the axschema namespace. The whole point of AX is that different providers may support different types.

     

    The fact that scenario 2) and 3) (when given the proper attribute types) do return valid data from MyOpenID clearly shows that they support AX. The problem is the inconsistency in how ACS reacts to these requests. When no data is returned from the IdP, everything works smooth. When data is returned, ACS fails with an error stating that 'openid.ax.value.email' is missing. If this was a problem related to the response produced by MyOpenID, why doesn't ACS fail with the same error when the attribute value truly is missing in the response?

    Here are the two responses given back to ACS:


    1) https://oktaset.accesscontrol.windows.net/v2/openid?...
    &openid.claimed_id=http://myaccount.myopenid.com/&openid.identity=http://myaccount.myopenid.com/
    &openid.mode=id_res&openid.ns=http://specs.openid.net/auth/2.0
    &openid.op_endpoint=http://www.myopenid.com/server

    2) https://oktaset.accesscontrol.windows.net/v2/openid?...
    &openid.ax.count.email=1&openid.ax.mode=fetch_response&openid.ax.type.email=http://schema.openid.net/contact/email
    &openid.ax.value.email.1=doe%40test.com&openid.claimed_id=http://myaccount.myopenid.com/
    &openid.identity=http://myaccount.myopenid.com/&openid.mode=id_res&openid.ns=http://specs.openid.net/auth/2.0
    &openid.ns.ax=http://openid.net/srv/ax/1.0&openid.op_endpoint=http://www.myopenid.com/server


    In 1) only the non-ax specific values are returned. In 2) a count of 1 for the email attribute is given along with the type and a value. ACS is quite correct in that 'openid.ax.value.email' is missing, but 'openid.ax.value.email.1' is there. Since 'openid.ax.count.email' is provided, according to the spec this is the correct way of naming the attribute.

    As far as I can see here, ACS does not fully implement the AX standard.

     

     


    - Peter - http://kodecompagniet.com
    • Editado Peter Lillevold segunda-feira, 8 de agosto de 2011 23:13 Fixed long urls
    • Sugerido como Resposta NanaNancyNeuhaus domingo, 29 de abril de 2012 16:23
    segunda-feira, 8 de agosto de 2011 23:12
  • Hi Peter,

    I talked with the product team.

    There are two issues here:

    1. MyOpenID appears to support AX, despite the fact that their XRDS document does not list it.

    2. MyOpenID is using a non-standard email address attribute. The axschema.org identifier is used by most providers, and is the only one ACS supports. The customer can’t expect to simply change to a different identifier and have ACS continue to recognize it as an email address.


    We could file a bug on ACS to recognize other identifier types (see http://blog.nerdbank.net/2009/03/how-to-pretty-much-guarantee-that-you.html), but right now Google and Yahoo are our primary scenarios.

    Thanks,

    Carson Wang


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    quinta-feira, 11 de agosto de 2011 02:25
  • Hi Carson,

    on 2) yes, what I was taken a bit by surprise here is the fact that axschema.org is considered the standard type schema and that ACS is hard-coded to transform axschema values into the schemas.xmlsoap.org schema. The whole purpose of the AX protocol attribute handling is for providers to be able to exchange attributes from whatever schema they see fit. 

    If a bug should be filed, I wouldn't suggest that ACS is hard-coded to support even more schemas. Wouldn't it be better if ACS could pick up whatever attributes is given in the AX response and bring them into the rules engine? This is what the engine is there for, transforming whatever claim types coming in from the provider to a suitable output claim type. 

    That way ACS would indeed be future proof and able to handle whatever type schema is deemed "standard".


    - Peter - http://kodecompagniet.com
    quinta-feira, 11 de agosto de 2011 09:11
  • Hi Peter,

    Thanks for the feedback. I believe the product team will evaluate it.

    Thanks,

    Carson Wang


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    sexta-feira, 12 de agosto de 2011 02:15
  • That is great,

    excited to hear the results!


    - Peter - http://kodecompagniet.com
    quarta-feira, 17 de agosto de 2011 10:16
  • I also vote for this.  Crazy that myOpenID, one of the main, if not the most visible OpenID providers is not supported.  An unfortunate and significant miss.
    segunda-feira, 14 de novembro de 2011 07:24
  • myopenid has a policy of selectively supporting AX - depending on the subscription level of the user. Those who pay get AX, in short. The rest get a core service, where the IDP acts only as an authentication (challenge) authority, and not an attribute authority.One could offer different endpoints for those services, but metadata in openid is too immature for folks to use such practices. Its hardly WCF grade design, remember.

    If a spec says "should", and the vendor does not heed the advice, the interworking failure is due to the party that ignored the should. Should means do it, to maximize interworking using common conventions. If you dont care about maximal interworking (common in startups, trying to control the mindshare), one takes the option to ignore the should advice.

    I used to make myopenid as the gold standard. I no longer do. What I care about is that google, yahoo and microsoft interwork. I care that the Azure ACS is open to myopenid (so strange caboodles of vendors dont dominate). But, as the commodity market matures, one expect convention to take precedence over technical options.

    Ive found ALOT of resistance to interworking with ACS, in the more traditional SSO vendor community. Its frightening folks, since its rapidly commoditizing the marketplace and bringing price down (to what the masses can afford). It's displacing the (ultra expensive) enterprise and ASP markets many folks though was doing to be a gravy train.

    segunda-feira, 14 de novembro de 2011 17:31
  • Peter,

    as far as I can see, myopenid doesn't have a paid subscription, but that's a different discussion.

    The case I've been trying to make here is that it is not MyOpenId that doesn't do what it is asked to do. On the contrary, it serves up attributes using attribute exchange when asked for.

    Rather, it is ACS that isn't doing what it "should" with the incoming attributes, plainly because the data coming back from MyOpenId is of a different namespace.

    So, I'm not surprised that you find a lot of resistance to interworking with ACS. It clearly discriminates other data namespaces, which to me seems rather silly. ACS is clearly capable of handling data in namespace X, but plainly ignores data in namespace Y, even when the data is served up using the exact same protocol.

    I do care about ACS, that's why I bother having this discussion. ACS fills a need in the app space where we as developers have to support a lot of IDP vendors, we need "reach". 

    I don't care if my users want to use their Google, Yahoo, Facebook or some other OpenId provider. But I do care about freedom of choice, and ACS promises to fulfill that. And if you think the whole world will end up using only Google or Yahoo, history shows that you would be wrong. You said it yourself: at some point you held myopenid as the gold standard, now you don't. These things change. And that's the clue, none of these providers are "the golden standard"

     


    - Peter - http://kodecompagniet.com
    terça-feira, 15 de novembro de 2011 08:28
  • myopenid offers corporate subscriptions, on a sliding fee scale. It also offers free accounts. I researched both (when trying to get an viable openid solution, about 2 years ago). I didnt go with myopenid, despite the technology clearly having a "clean edge". Its a NICE and mature and profesional piece of technology - one can REALLY understands the target programmer.

    Should ACS support any namespace used by the IDP? I dont see why. Honestly. ACS is not an app platform, but a fabric. The bane of the world is every standard reimplementing FirstName in its own namespace, forcing endless mapping. I know... since in realty we maintain 100 of them to suit every cities "unique requirements" for naming the 500 attribute that name, title, identity the nth attribute of a property (and its EXPENSIVE). 99% of the time, two neighboring cities change the names PURELY to compete (and segment that local market, put up barriers to entry, etc).

    ACS is not multi-purpose gateway - and its not there for IDPs. Its an RP-STS and part of a platform as a cloud service It is there to augment SP-side processing, augmenting their value points into the assertion to SPs that are thereby insulated by the vaguries of IDPs. Often those IDPs are anything but (they are almost all app vendors, really). Clasically, an RP-STS a role mapper- and discovery support service to cloud endpoints in a multi-tenant world.

    The whole reason I prefer ACS is because I understood what the cloud does vs I can do in a bit of code, as an app programmer. I wanted the case that my app programming knows NOTHING about IDPs, and their namespaces, their metadata, and their anything else. True - I also care nothing for the IDP attributes or their profile management services  or their community governnance services - we ONLY want a persistent name and the fact that the user passed the authentication challenge. When our users are challenged with Google 2 factor plugin on their phone, its wonderful - as its the equivalent of being challenged with an RSA securid card. Its a free securid-grade solution, that is. And, thats ALL it is. The same goes with Live and Facebook - to us they are free Passmark cookie and anti-fraud checking services. Im happy to pass users back to the live/facebook/google apps sites...as a return favor. Everyone is winning, starting with the user.

    I looked at the webmatrix beta yesterday - IIS 7.5 hosting webmatrix.latest, hosting joomla, drupal and wordpress. It also hosted a demo ASP.NET site, that  came with native classes for OAUTH, openid (i.e. no ACS). It has a lovely demo of an app that within 5m of installation is firing off the Openid exchange (with Google) and then invoking account linking, dynamically creating an account on the fly using the typical .NET 2.0 membership framework. There, with such TIGHT integration with the app controlled by the programmer, I think one can argue differently to the ACS case - as its QUITE a different implementation. The programmer is in charge, and the app wants a close knit integration with Google's profile service. Presumably, one can use myopenid, too. Its more of a classical case of the app being a "plugin" to facebook, rather than an app wanting to use (merely) a SAML authentication auhority (where these days that use case might be delivered using openid bits on the wire instread of the SAML bits on the wire, not that anyone could care less).

    In summary, use ACS only when your app is cloud-ready. If you are not leveraging a PAAS architecture, but are still building server farms using ASP principles, use the right framework. There are several, in the windows family, and they interact with IDPs in different ways. Town cars have a different feel to cars tuned up for long distance highway driving through Montana.

    I dont know why Im saying this. This is the for the azure folks to say. BUt, Ive found Azure sales folks are largely clueless when it comes to pitching AppFabric... There is definitely a disconnect between the Azure operations and sales team, and the product management team, on ACS. This is a shame, since I think the product management team got it EXACTLY right (having learned to distinguish so subtly the architectural issues, as above). As the other software sets come to maturity (e.g. the webmatrix case), perhaps it will become EASIER to distinguish.

     

    terça-feira, 15 de novembro de 2011 12:18
  • Sadly, most of your argumentation doesn't belong to this discussion. But I'll highlight one interesting bit:

    Should ACS support any namespace used by the IDP? I dont see why. Honestly. ACS is not an app platform, but a fabric. The bane of the world is every standard reimplementing FirstName in its own namespace, forcing endless mapping. 

    In ACS, have you ever used the "Rule Groups" and added a "Rule"? The Input Claim Type field shows that ACS indeed already support any namespace used by any IDP. And honestly, why shouldn't ACS support any namespace? The whole purpose of the claims processing rule engine is to do exactly this: take any claim, being it google.com#name, facebook.com#name or whatever #name the IDP throws at us, and transform it into one claim type known to the RP. It already does this! Why are you arguing that ACS shouldn't?! ACS saves us from "the bane of the world", it is there to do the mapping for us so that the apps don't have to!

    ...and your next sentence really doesn't make any sense... Yeees, we all know ACS is not an app platform. Noooo, ACS is not a fabric, "fabric" is part of the Azure Fabric/AppFabric product naming and has nothing to do with what a piece of software is. ACS is a service providing authentication and authorization.



    - Peter - http://kodecompagniet.com
    terça-feira, 15 de novembro de 2011 13:03
  • I really enjoyed your arguments. Well done.
    quinta-feira, 1 de março de 2012 15:35
  • Peter's argument really comes down to the belief that some configuration mechanism for IDP entities, of class openid, should enable some measure of configuration allowing the tenant to control the request's content. The example is openid (and its namespace for email). But, the example could be Live and my hotmail email claim delivered with OAUTH (vs openid 2.0).

    If I was designing/building an ACS concept, I would not support what is asked for - providing detailed control over the  claim negotiation process. It comes down to what role you assume ACS is playing.

    If I was building an ACS-like thing for my private trust spaces, perhaps I would do what is advocated...let static or dynamic metadata control the request building process used in the protocol. This is just "metadata-driven" programming - where metadata is a source of configuration information.

    The only thing I contemplate using (the passive side of) ACS for today is getting a first persistent identifier (from a variety of IDPs), and presenting a home realm selector service

    If I want to talk to Google, Yahoo, or MyOpenID for full "profile" information then I talk to them directly (using my own equivalent of ACS). At that point, I tune up each request for the "unique" way each IDP delivers its OpenID service (and every last one of them is "quirky"). I dont expect ACS to be the only means I have of talking to IDPs.

    I only use indirect-ACS "to bootstrap" a then-direct relationship between SP and IDP. ACS establishes a baseline of trustworthiness that is, and then I take over. I dont expect to be a dumb RP site, 100% dependent on ACS, paying a 1c for a token on every MVC4.0 API call. Im happy to pay a fee for the trustworthy "introduction" to a well-identified party, however. The introduction is now a "fact" in my own account enrollment process for that new subject.

    ACS is obviously a work in progress, evolving from being a ws-fedp STS factory into a more general trust broker. There is a huge space of choices concerning what role to play in the trust brokering business - and one will hear 100 different rationales. Some folks want you to be a control point, acting as a proxy for IDP governance. Others want you to be means of offloading matters mostly of concern to the SP, mapping Google groups onto local roles. Some want you to be just a protocol gateway, between blob formats. And yet others want you not even exist (since your very nature removes the friction around a user having several IDPs, allowing users to use several when talking to the same RP site).

    quinta-feira, 1 de março de 2012 16:48