rsa-sha1 signed simple ws-fedp response–for max interoperability (e.g. WIF/Visual Studio STS to PingFederate)

Steve Syfuhs answered my call for information on how to make a simpler kind of federation response, including the usual signed assertion.

The  project I built is download from here and the desired output is shown below (using the Fiddler tool and a Federation ‘inspector’, all from community members):-

image

To repeat the experiment using school-boy computing apparatus, install visual studio 2010 and the WIF SDK.

Then add the website, using the Claims Aware website template.

On that website project, run the STS wizard and add a (passive) STS project. The former is the relying party of service provider (SP) relying on the signed assertion produced by the latter IDP – the asserting party releasing an identity claim about someone or something. Note the default.aspx.cs file.

image

To change the output message formatting from its defaults, perform the following modifications to the pre-generated code in default.aspx.cs:

image

At 1 declare the serializer classes (for the older message formatting regime that we seek).

At 2, use the serializer in a replacement method call that processes the signin message received from the SP, requesting a response with assertion. You will need to resolve types, which will add package references:-

image

While you are at it, you MAY wish to maximize interoperability (at the cost of introducing “relative” lower strength in your crypto). By using SHA1 (or MD5), it will be now 10 years rather than 20 years before anyone attacking you that you actually care about can spoof the signature checksum – on your message whose noted expiry is 5m from now anyway…). Certain sites upon receiving assertions verify signatures only when signed with the RSA/SHA1 crypto combination and 1024-bit public keys

So that the assertion be signed with RSA/SHA1, alter the constructor of the STS configuration class thus:

image

“http://www.w3.org/2000/09/xmldsig#rsa-sha1”

http://www.w3.org/2000/09/xmldsig#sha1”

image?

We can go further into the maximum interoperability argument and ensure the assertion has an Authentication Statement indicating an authentication instant, authentication method, subject name and a couple of authorization attribute required by Azure AD (in its Office 365 incoming Federation Gateway incarnation).

This requires two steps:

image

Step 1: make claimset (note the Prip UPN (http://schemas.xmlsoap.org/claims/UPN) , particularly) and assign the claimtype of the name(identifier) claim

and in the STS class’ call back method for GetOutputClaimsIdentity() method apply our trick to make Authentication Statements appear in the (SAML 1.1) output assertion:

image

Step 2: ensure the output ClaimsIdentity has isAuthenticated property set true

With these additional changes we get as output on the wire something I’ve sought for 2 years!

image

Now the open question is: is this response compatible with (i) Ping Federate’s ws-fedp SP, (ii) the Shibboleth ws-fedp SP, and (iii) Office 365?

Yes, I’ve gone back a decade and laid out the non-optimal steps in schoolboy programming style – but that’s what maximum interoperability and maximum tutorial value often entails (since highly politicized vendors/academics ensure modern profiles don’t actually interwork in the wild, using some semantic trick or other to help “structure the market”)

Help on getting this far due to : Ping Identity (lots and lots of what-to and how-to), Steve Syfuhs, (how to go back in time in WIF), Dominick Baier (for Fiddler ws-fedp inspector and patience beyond measure, given the likes of me).


So, to testing with Ping Federate! lets create a connect from its SP agent to this STS – intending the websso assertion to play the role of a OAUTH grant:

image

image

Concerning the mapping from SAML assertions to OAUTH persistent grants (one of the advantages of paying for commercial grade servers!)

image

Concerning the mapping from assertion to access token we play a little:

 

image

And of course we import the STS’ certificate into the Ping Federate IDP connection, exporting it from windows thus:

image

makinga complete Ping Federate IDP OAUTH-IDP Connection of

image

When we try it we in the OAUTH context, acting as the phone app doing a redirect via its web browser to get the first authorization_code after a user authentication (via ws-fedp websso interaction)

image

We get an interworking success between (non SAML2P) WIF IDP and Ping Federate (for My first time)!

 

image

image

and RSA-signed JWT of

 

“eyJhbGciOiJSUzI1NiIsIng1dCI6IjcwVzNuUFJDQ3pTZVh1cXdzQlZ5MktNU01QayJ9.

eyJVc2VybmFtZSI6InBldGVyQHJhcG1sc3FhLmluZm8iLCJPcmdOYW1lIjoiQWNtZS

wgSW5jLCIsImV4cCI6MTM2NTgwNDAyOCwic2NvcGUiOltdLCJjbGllbnRfaWQiOiJh

Y19jbGllbnQifQ.TwYaXEZG21No4CeocPK7O_CCzx4PjUFIr6KfcD6d1zI-496vSl1xzS5UCqhjTltNuibUWvRntK77lbwQMfxbSeadvs5HPq0DdAdMKWHxbJkY93

aMbutVj-GzuaFzXxzHGyRn-U2rwWhRzAcJcrHz9Mb242YctiJadf30z9rDZ_7CQNjrFJNRPEgH6SFy9659Cof-ZvkarhqGKRRskv6ZqWBXLbRIO2GZrfhA6UesK_AT60QOin-eARRRv5bJDCwE6yO3OCcd35RiR0jaY4mGFVJmU2Nqy6_FIqPXCqbrx46M-07TMunA9qCUvgAG1CbhYsPyZhkl49uxZxCvy5u4og”

Just one gotcha to note in the original Ping Federation server IDP connection config:  one has to use the SP’s wrealm to give what is normally indicated in the wreply:

image

Perhaps repeat the steps – and let me know what factoid I’ve omitted from the schoolboy’s science project writeup.

P.S.

To make the assertion from the STS indicate am authentication subject name with a particular format,

image

vs

image

one makes a slight modification of the code:

image

Thanks to Steve Syfuhs

 

End.

Posted in pingfederate, SAML, SSO

from WIF ResponseCollection to just Response

By default, a WIF passive STS built from ASP.NET template samples produces a response of the following form:

image

Assume that was a later ws-trust and ws-fedp profile than what we want.

Now, what we want – in practice – is a response of this form:-

image

image

so what do we do in WIF programming terms – within the STS callback class or configuration class to make the latter?

Posted in SAML, SSO

1954 zero knowledge

image

image

image

A couple of things occur to me, thinking back to 1954.

First, one should think of a rotor as a means of producing distance (or difference). One thinks of the input set as a relative frequency. The inner product of the two is a particular space, where one deals with mean-set – based on random walks. A sequence of rotors produces the weight function when the “domain of definition” covers every vertice, with its atomic probability measure. With this condition, we enter a world of :total definition, which allows the notion of minimum distance to be the same as minim weight, which is a measure of the mean set in the asymptotic limit.

Second, the polish breakthrough in early enigma cryptanalysis was based on cataloging the conjugacy classes for particular substitutions of boxed alphabet (to use GCCS terms). The very notion of public key becomes apparent, back in 1954 terms, when the secret value s, as in w is conjugated by s giving t, operates in a world where t is only one member of the conjugacy class. This if course was the case with enigma/cyclometer cryptanlaysis

Posted in crypto

realty netmagic demo–handoff to Office365

Of the 6 billion humans on the planet, this will be interesting to about 3.

http://sdrv.ms/Z6btdj is a source project – with a trivial windows form – launching outlook, lync, browser. The point is that the thick clients be configured to talk to enterprise-class endpoints of Office365 – supported by a federated configuration that causes the clients/office to talk ws-trust back to an instance of an IP-STS running locally. In our case, it was a trial of Ping Federate’s ws-trust STS feature, with a username token processor addin.

Source may change to showcase using Office 365 APIs, etc.

Posted in SAML, SSO

Ping Federate active STS with Lync Online

When the logs say the following

image

It means that the relevant audience fields for legitimate token processor endpoints REALLY does not have http:// (or https://) scheme at the front – even if your expert in Ping Federate tells you otherwise.

image

note, you only really seem to hit this issue when you invoke the lync client component of your Office 365 solution.

Posted in pingfederate, SSO

From Realty IDP to Google Apps for Business (via Ping Federate and PingOne)

Let’s create a modern Google Apps for business account – similar in concept to our recent Office 365 tenants.

image

So, just as we have Administrator@pingtest2.onmicrosoft.com (accessible via https://office.microsoft.com launch point) in the Office365 world, we also now have Administrator@pingtest2.mygbiz.com (accessible via http://www.google.com/enterprise/apps/business/) in the Google world.

In parallel, set up an even-longer frog-hopping IDP chain. We configured the forward hops from our Realty IDP to a local PingFederate gateway to a PingOne cloud instance.

One authenticates (via websso of course) to ones personal cloud desktop (currently provisioned with no SP places to do.) But, the Google Apps domain noted above will shortly be added!

image

access via https://desktop.connect.pingidentity.com/clouddesktop/rapattoni.com/

image

One notes just how much “Google analytics” (the nice word for spying) PingONE is doing on the transactions – from where to where, by who – which may upset quite a few Realty boards – who don’t want such tracking properties given to commercial tracking partners. For Realtors, working there social network is what gives them an edge. Offering free SSO or reporting is not going to fly – if the expectation is that the tracking/reporting can be resold to others (as is usual in the US). Sigh! (When will American corporations get it!! Spying is NOT ok, no matter how you pitch it!)

Anyways, to add Google as place to go in this “Federation Gateway”, we go back to PingONE Administrator mode (which is not itself not websso-powered, which is annoying).

image

Via the apps catalog (of SSO-enabled “SAAS” vendors), we select Google, for which above we pre-prepared our tenant:

image

In a rather frightening page we see the hookup instructions and the double-ended invocation URL with which to talk sp-initiated wbesso upstream to the IDP to mint a local session in the “desktop app” before doing a trial landing on the Google App, which will duly do sp-initiated websso against the session in the app. (We do lots of this in Realty, too!)

image

(SSO) URL is  https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=9038ea7f-9b46-4d81-8f1a-010a6dbc6826&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

We save the pingone “signing” certificate for use later (and to be honest, I don’t actually know what this is for, yet). But, obviously it’s important for something!

image

Now, having JUST created a (working) Google Apps domain or this test, I’m faced with some horrifying text (since I don’t know as a mere dumb administrator….which of its conditions are true). All I know is I just finished signing up with Google Apps!

In order to allow your users to Single Sign-on to Google Apps, you must enable your Google Apps domain to support Single Sign-on. To do so, log into your Google Apps domain and then follow the instructions below.
P

lease note that if you are using Google Apps for Business as your Identity Provider (and NOT using AD Connect, PingFederate, or a SAML solution), then you should not add the Google Docs application from the PingOne Application Catalog. Instead, to add Google Docs to your PingOne account, you should go to the “My Applications” page, click “Add New Application”, and select “Manually Add New Application”. You can then create a link to Google Docs, using the following URL format: https://docs.google.com/a/${YourGoogleAppsDomain}

So what do I do!!?

Going back to Google, the company forces me to reveal my phone number as an administrator(for some security pretext). I feel lied to (whats new! About Google …and is USG relationship).

image

Using my intuition on how this all use to work a couple of years ago (when I last fiddled with anything Google’ish) we can presume that we need to focus on SSO setup:

image

we fill this in thus (eventually figuring that the “idpid” value comes from a parameter buried deep in the pingone URL for our instance of the federation Gateway)

image

Then upload the PingOne federation-signing cert (whose function I can now understand). In some absolutely crappy design, this act destroys all the other form inputs (so carefully input). Google is not the tech-firm it once was! So, we do it all again. This is the last time, before I abandon this.

image

After I consent to use SSO screen, we add a non-administrator user (much as we might license a user in Office365 land):

image

we get

image

image

http://www.google.com/a/pingtest2.mygbiz.com

SO, expecting websso (to my IDP, via the PingONe Gateway), I get a google signin screen, strangely. SO I enter the temp name/password, and get:

image

which leads to the usual google apps applications. But no websso! So lets try the double-initiator URL from PingOne:

 

https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=9038ea7f-9b46-4d81-8f1a-010a6dbc6826&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

image

Now, we have evidently lost the PingOne configuration! (probably because we failed to resume config back at PingONe, after doing all the Google SSO config).

Do I have the heart to try all this again, using values from (SSO) URL ? https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=ce63276c-6cf6-4454-aae0-7c62097302fb&idpid=759a92dd-fa1c-4085-8a2c-bcbd38334d5d&appurl=https%3A%2F%2Fdocs.google.com%2Fa%2F%24%7BGoogle+Apps+Domain%7D

well yes, since there is stuff to do (that makes sense):

image

image

giving us something that MAY be important ( logically for pure SAML2 SPs that could do all this manual work rather better than google does it)

image

image

we now see more what we would expect (with the sp-init flow back to the Realty IDP) creating a federation gateway session, than from there trying to handoff to google ACS:

image

What is sent to Google’s ACS is this:

image

So if we now ensure that we release an emailName in the namespace Google expects,

image

we get….at the policy middleman (sigh, at the desire to exercise control concept)

image

if we arm the “group” (and this took multiple tries)

image

we eventually get to SP behavior (which is still a yet more of a pain):

image

if we log out of the persistent Admin session, we eventually get the experience we should have had 2 hours ago:

image

It works. But I don’t know how many people would be THIS persistent!

Posted in pingfederate

WIF SDK and dotNet 4.0 SAML authenticationStatement (and cert)

We can make an Office365-like assertion using nothing but the default template for adding a new website using the ASP.NET passive STS template…

image

We managed to make a trivial change to the auto-generated starter code so all the work of the previous memo was output:

image

The original code…

image

…becomes (in principle)

image

Yes, that little dance of 3 lines causes the outputIdentity to have its isAuthenticated property set..and for the nameidentifier to become assigned as the authenticationStatement’s subject. The critical thing to do is have the “custom” (or any other named object) present in the construct. It sets “IsAuthenticated=true”  – which triggers the output formatting (as you now would expect, no!)

The idea came from reading http://leastprivilege.com/2012/09/24/claimsidentity-isauthenticated-and-authenticationtype-in-net-4-5/ – which had the hint worth following up….

Note if you omit the first two lines, you can set the authorization statement’s nameidentifier (but no authenticationStatement – obviously with no subject value equal to the nameidentifier – is produced.) Similarly, you can add claims of authnInstant and authnMethod by hand to the output bag. These will create an authentication Statement (but no subject field, within)!

All makes perfect sense (now I know!).

image

Now, what do we do so that the formatting of the ws-fedp “wrapper” tags around the assertion be the simple one-element response (vs a collection of 1 responses) – just like that produced by ADFS 1.0?

 


Gawd, I feel so stupid. But not as stupid as the three American doctors who recently told my wife she was constipated (when it was a horrendous gall stone, requiring organ removal). Or the other American doctor who  told her the rash was nothing (when it was Shingles)… But, thankfully MRIs and CatScans (using nice noise reducing algorithms that are (nice) sideeffects of the cryptowars) save the day for internal medicine, since now you can actually see what’s going on…if only you have the skill to get passed the money-saving insurance company trying to prevent you getting access to them…

But having 5 advanced imaging scans available in properly-funded/profitable American hospitals doesn’t always help (as my daughter found out, yesterday). Assumed to be major kidney pain issues (logical, given the pain source and the surgery history), noone  – including me – looked for 4 weeks at the strange shadows near her spine on the CT scan, just where certain back muscles attach…and which can be *so* stressed they spasm wildly…at the merest touch

Posted in SAML, SSO

making a simple assertion with authenticationStatement

We download older Windows SAML code from packtpub.com, trying to go back in time and think how Microsoft though about topics BEFORE the WSE2/3 and WIF era. The assumption is we will closer to Win32 and the TCB. We look at a simple tester program, Chapter one, unit 2, which we amend so the form is more like what Office 365’s Federation Gateway will expect and demand.

image

First, make a signing-capable cert – but amend the instructions a little (to update the maximum expiry date!)

image

one amends the descriptor structure for the assertion to add the desired attributes an the authentication statement:

image

We get the assertion as desired, though its signed (in this program). Of course, Office probably doesn’t want a signed assertion. It wants a signed ws-fedp result message (bearing the signed/unsigned SAML assertion)

But, we have got closed to the “raw machine”.

image

If we compare this to the output of Ping Federate IDP (acting as a Proxy IDP to our Realty IDP), where Ping Federate is itself a proxy IDP to the MicrosoftOnline IDP … invoked by the Office Federation Gateway (itself invoked by Exchange ONline SP!)…

image

we see that we are missing the audience controls and fail to carry the certificate. And obviously, we are as yet missing the outer ws-fedp tags.

SO lets fix the obvious stuff.

To add the audience conditions and set the nameformat proeprty on the UPN as nameidentifier:

image

thanks to http://stackoverflow.com/questions/1348947/audiencerestriction-in-saml-assertion we added:

image

To add the certificate to the signing block:

image

thanks to http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/9a2c881c-5094-40be-a650-1fe27fe465fc we changed the keyIdentifier to the X509Raw type:

image

from image

Posted in SAML

Realty IDP to PingFederate IDP to Office Federation Gateway to SP

some notes on several sp-initated chains, mixed with idp proxying  and relaying.

To configure, ensure the realty IDP uses the desired ping federate server (with the capabilities to talk to Office with both passive and active sso protocols):

image

1: override the default stem of the ping federate server

2. mandatory attribute, when asserting to the Ping Federate SP connection

3. note the absence of the trailing ‘/’ (since this values is concatenated with the path given by PF on the callback,with its dynamic path components – presumably for security)

we can see the chain and assertion path here:

image

Posted in office365, pingfederate, SSO

dotnet validating Ping Federate’s RSA-signed JWT

Let’s update our ASP.NET SP old project – so that the OAUTH2 provider for PingFederate now verifies the access token in JSON format (rather than following a reference).

First, we set the path and loading parameters for the certificate for verifying the RSA signature (as the only parameter that gets controlled in this “liberal” security concept)

image

The Get User callback has to change similarly:

image

Posted in pingfederate

PingFederate’s JSON string array; using SAML token to fulfill access token contract

In the advanced settings section of the access token management page for JWT tokentypes, note the option (at red 1 below) to serialize scopes as a space-separated string (rather than as a javascript string array). Obviously, this issue hit us yesterday – where the decoder happened to use very simple assumptions about the array: being a name-value pair set representable as a dotNet dictionary<string, string>. We fixed it by amending the decoder. We realize now we could have fixed it by reconfiguring ping to simplify its token formatting for simpler (almost trivial) decoders.

image

At red (2) above we see our attempts to expose some “contextual” parameters, usable in mapping.

Below, we also note the contract we  formally disclose about the tokens content (one day in OAUTH metadata, presumably, once the “new” standard catches up with “old”  SAML). We add petername.

image

Now when fulfilling that  contract, why can we not fulfill petername from any of the inbound SAML assertion’s attributes/claims? Why are things restricted to the SAML subject? This makes no sense (though I can see lots of dogma reasons, for it).

image

I think the answer is to first extend the attribute contract – thinking now of the “OAuth SAML Grant Attribute Mapping” much as one thinks of an SP adaptor contract definition.

image

Posted in oauth, pingfederate, SAML, SSO

Validating the RSA signature on a signed JWT from Ping Federate

If we upgrade the JSON token project in this really old (by one!) memo to dotnet 4.5 and compile things using visual studio 2012 (upgrade2!) can we verify the JWT from Ping Identity’s Ping Federate server? Recall that a signed JSON object is subtly distinct from a signed JWT (intended to be used in token passing protocols).

http://www.cloudidentity.com/blog/2012/11/20/introducing-the-developer-preview-of-the-json-web-token-handler-for-the-microsoft-net-framework-4-5-2/ describes the validation procedure

image

Assume we forget all the Azure AD type concepts, and just do the bare minimum to verify a token, with a preconfigured cert.

So, lets install visual studio 2012 on our host (with the Ping Federate based OAUTH AS and STS) so we can compile our very trivial token decoder project against dot net 4.5. This also allows us to reference the JWT security token handler assembly, having installed the capability via nuget (searching on JWT)

image

Obviously, now, we have a reader for the base64(url) string encoding and a token reader:

image

Once we get the right (one-level verifying) cert loaded and more correctly identify the audience and issuer (i.e. swap the above), we get a verified principal:

image

at this point, we presumably go off and create a cert chain and check the cert is valid, re its chain, CRLDPs, OCSP pointers, etc etc.

Posted in pingfederate

decoding an OAUTH signed JSON token from PingFederate

Assume the token is signed with RSA and all we want to do as an OAUTH client (SP) is decode the attributes within (using a project such as this):

image

Let’s assume that this token is still subject to interoperability testing, within the community of OAUTH vendors. So, what we see in this email is “for future interest” – to get a feel for where products will be, shortly.

Within the Microsoft world, and the office 365 world in particular with its recent Exchange Online support for OAUTH in the API, we see the project:

image

http://code.msdn.microsoft.com/officeapps/Mail-apps-for-Outlook-10c039dd

we can add a test page that calls the decoder class, using the access token minted by the OAUTH STS above. We have to modify the project above, which is too “microsofty” (and makes assumptions about mandatory JWT properties.

image

we some some very basic compatibility by making the following alterations to the original code:

image

We first just gut the project to get to a basic blob decoder – while waiting for the dotNet4.0 release of the formal JWT security token handler (which will do “local” validation of token signatures).

Changing Dictionary<string,string> to Dictionary<String,object> so that the Javascript deserializer is happy to parse the Ping-supplied array of scope strings, we have a basic information object:

image

A trivial project to decode the string supplied by Ping Federate then holds together as

image

The supporting (variant) base64 decoder is given already in the project

image

giving us

image

and

image

with an array (with one element) of scopes: edit

Remember back here for the JWT Security Token handler project work. The above is just enough complexity to get one going, particularly if there is an SSL “bearer” channel.

Posted in pingfederate

cert URL references in the OAUTH community

image

so https://localhost:9031/ext/oauth/x509/kid?v=1

image

Note how the response doesn’t use the internet/PKI mime types for (user) certs. Hmm.

Presumably, we can create a hierarchy of keyids, such as 1, 11, 111, 1111, where 1111 is the user cert. One can walk the ever-shorted keyids (111 truncated from 1111) and the constructed URL references based on keyid to “discover” the cert chain.

Can now I have an American patent (based on all this “original” thinking)?

Posted in oauth

trust, mistrust, certs and covert surveillance

image

http://news.cnet.com/8301-13578_3-57577887-38/apples-imessage-encryption-trips-up-feds-surveillance/

It is becoming generally known that the internet trust model (certs based on the likes of GoDaddy CA  and validation DLLs and “trust stores” in the likes of Microsoft Windows) was subverted in 1997 – in the “interests of America”. There is rarely anything wrong with the certs themselves or the cert issuing procedures (though military-grade subversion is the exception). What is subverted for the non-military goals of the likes of DEA is the process of verifying the certified evidence – so that communication is established to an imposter – able to pass the evidence threshold and test applied by (not particularly trustworthy [in the assurance sense] American-manufactured) devices.

In American crypto-political terms you first create, endorse and/or sponsor a trust system. Today, OpenID Connect is the (ongoing) equivalent initiative. And then you have a covert channel WITHIN THE TRUST SYSTEM itself – available to the elite of the society. You of course provide “legal cover” for the vendors, at both a technical rationale and liability level.

Strangely those who speak-up for “trust systems” seems always to find it appropriate, under the guise of national security secrecy (and/or wiretapping) rationales, to have a trapdoor within the trust system itself. In it, they are more trusted than others. And that is the secret – that not all Americans are equally trustworthy per se. Some are empowered to become an imposter of such as an apple-device (while being the actually the “non apple” device”). Note how wiretap rights includes (i) the power to induce the wire to be tappable, and (ii) placement of the communication tap (or intercept). Note the difference, first thinking in terms of 1950s wires and switches!

The journalist got it right, nothing when man-in-the-middle certs are issued (usually dynamically) with fields that trigger the apple (or other vendors’) trapdoor in the device’s trust system’s verification module. To hide the door a company like Apple (and Microsoft is no different…) does not lock down critical configuration files – saying that if the FBI/DEA has authority to wiretap this means – these days – this includes plant the “bug” on the computer (step (i) above). That bug can be altering the trust validation methods “in the name of the ‘user’” – as far as the device own technical security policy model goes. Thus no “compromise” of the technical security policy actually occurs, giving the vendor cover.

Weasel words, of course. But what else can Apple or Microsoft do? Its not as if they have any choice! They are American companies and America wants to spy – on foreigners (and locals). As loyal Americans, it’s the job of Apple and Microsoft to project American power (and ability to spy). Nothing new – whatsoever.

What will be interesting to Internet historians, one day, will be who, when, why and why not”! things happened at VeriSign – as it was indoctrinated into compliance with the trust practices of the US government. It was fun watching the transition of attitude (and how it was engendered). Not every immigrant or long-term tourist just off the boat gets to see such things happen, in real time.

Posted in rant, spying

chaos, attractors, and dimensionality

I’ve long had a suspicion that one of my tutors was a reformed cryptographer – having entered medical (informatics) research. There was just TOO much about the design of the first year computer science course that aligns with (UK) early history of computing (and the very folks involved in it).

SO it is that we can see in the “theoretical” part of the paper a nice presentation of what might also be called a cryptographic method (relating to hidden markov modeling).:

image

http://www.scribd.com/doc/50765865/CHAOS-THEORY-and-sEMG

The material above reminds of us Forney, teaching codes from the perspective of both modulation AND signals/control theory. we see development of these these next, focused around state spaces (much like those we saw analyzed in lattice-based codes).

image

http://www.scribd.com/doc/50765865/CHAOS-THEORY-and-sEMG

interesting to see “attractors” and multi-dimensional distance construct come into play, where an (math-style) “orbit” is just a trajectory in phase/state space – as multiple phasors wander around circle.

image

http://www.scribd.com/doc/50765865/CHAOS-THEORY-and-sEMG

Posted in coding theory

gabor and wavelet transforms

image

http://www.scribd.com/doc/50765865/CHAOS-THEORY-and-sEMG

The distinction properties of Gabor and Wavelet transforms – and the purpose of the kernel – are given above. The benefits are characterized thus:

image

http://www.scribd.com/doc/50765865/CHAOS-THEORY-and-sEMG

Posted in coding theory

appearance of noise (or not)

imageimage

noise academy

http://www.noisemachine.com/talk1/6.html

Posted in dunno

office365’s request to the UsernameToken STS

image

Office

The actual request from Office365 to our STS (Ping Federate) is shown above. We have the skill now to  have our code issue a similar request (as evidenced yesterday). It is a littler difference – so we can learn how to make it the same!

image

Local

When we look at the output sent to office (given the office request), we can again contrast it with the output sent to us (given our variant request):

image

office

compared to that delivered to our ws-trust client:

image

Posted in SAML, SSO

Schmidt’s propaganda ministry upping the hyperbole

image

http://redtape.nbcnews.com/_news/2013/04/03/17575854-bank-website-attacks-reach-new-high-249-hours-offline-in-past-six-weeks?lite

Tame journalists complying in the “re-education” campaign.

Poor little America, bullied and defenseless against the evil foreigners.

Should look for the parallel story in the UK, probably set for the Sunday edition. Evil Irish Catholics use Libya to kill 12 year olds. Ah, but both those boogeymen are dead (literally or as issues). So what is the UK propaganda story line? evil Iraqi “masterminds” with 52” waists? The zombie osama army? I know, it’s the Ecuadoreans fault, led by Assange. We have to remember the UK/Paraguay war, and all its 300-year long trade implications  – and let’s recall the long historical ties between Ecuador and Paraguay, those special socialist/nazi bonds that unite. Perhaps they will blame folks from the Argentine…

Posted in rant

WIF, nameidentifier format and AuthenticationStatement subjects

http://zamd.net/2010/04/27/configuring-saml-assertion-subject-name-and-format-for-a-wif-sts/

image

For the subject element, presumably one uses

image

Posted in SAML

PingFederate’ Office365 ws-trust config applied to ACS demo’s IStringService

image

image

Ping Identity helped us configure the connection between our Ping Federate server and Office 365 – for both active and passive protocols. Using the same exact server, we modified our little client to talk to the same ping federate server over ws-trust seeking a bearer assertion to present to our own “emulation” of Office 365. The (very quick, proof of concept) modifications  are shown above. They are (1) include the saml1.1 handler, and ignore audience issues. Also, ignore cert/issuer-name errors, for now.

The modifications to the client are trivial:

image

The result in the string service are what you’d expect:

image

Ping Federate’s logs indicate a response format with the following statements:-

image

Posted in SAML, SSO

using bearer token from ACS (and later PingFederate) for client/server web service call

The code at stackoverflow enabled us to get a token from ACS, issued with the symmetrickey type – fit for presentation to an IService – setup with the bindings from the ACS samples for the username token webservice. It’s obviously a minor change to migrate from the certificatebinding, given below, to the usernametoken binding.

image

http://stackoverflow.com/questions/5598388/how-do-i-configure-wcf-to-use-a-custom-realm-in-urn-format-with-azure-acs

This bit of code shows what is happening behind the scenes (with regard to such as interactive mode (not), service credential negotiation (not), and security context setup (not).

We changed it a bit so once again we have ACS issue a cleartext bearer token – by (i) reconfiguring the Relying Party at the console to remove the encryption process, changing the binding for ACS to request a bearer token (vs. symmetric-keyed token) and setting up the channel to the IStringService to note that a bearer token will be presented in the SOAP header.

image

Obviously, in the implementation of IStringService, when configuring its host, one also needs to tell the channel to expect a bearer token, too:

image

looking at fiddler we see the interaction with ACS:

image

the channel between client and server hardly seems simple, though:

Request:

image

Response:

image

if we turn off the ws-security enveloping in the client, we finally get something simple (and pure bearer token, over https):

image

image

With the ws-security message-level security model, we get what you’d expect: in the service:

image

Posted in SAML, SSO

Using WCF and WIF to perform WS-Trust active claim requests – Alex Thissen Weblog Build 1.15.10.1971

http://www.alexthissen.nl/blogs/main/archive/2011/07/18/using-active-profile-for.aspx

Posted in SAML, SSO

Using Azure ACS v2 to generate an Office365-headed SAML token from a UserName Token

We installed and ran successful, as given, the ACS sample project for webservices (username version). Then, we amended it as follows. To run it requires a minor re-configuration of the ACS service already supporting the usual demo so it now acts as a very simple token processor. Our project files are downloadable from here. First download the set of projects from here, and overwrite the username project in webservices/ with my amended files. Don’t forget to configure you own Azure ACS parameters in Common/!

Outside of any complication and wider context (ws-secureconversations, issuedtoken bindings etc) it just takes in a username token and produces a SAML token. The inbound username token is wrapped in an RST and the saml (2) token is wrapped in an RSTRs. Both messages are communicated to the ACS ports using the ws-trust (13) protocol.

image

http://blogs.msdn.com/b/willpe/archive/2010/10/25/windows-authentication-adfs-and-the-access-control-service.aspx

To talk to the ACS endpoint we used simple ws-trust Client APIs provided by the Microsoft.IdentityModel library, as given above.

Don’t forget in the ACS console to turn OFF the encrypted token requirement.

image

This should be enough surely to now exploit the API that allows one to inject a token into the channel handling, now?

Now, if we just add a couple of conditional rules bound to our verified service principal’s name (the nameidentifier claims type) and change the token type to saml1, and add peter@rapmlsqa.info principal to the service identity list, we can mint

image

But, will it work with Office 365’s Federation Gateway (and all the certificate/token/DRM minting stuff from ADRMS)? To my knowledge, I cannot control which signing algorithm ACS v2 uses, for example – being forced to us what Microsoft sees fit (SHA256, for example). Do I need to have sha1 support (assuming office demands it?)?

Posted in SAML, SSO

PingFederate’s correct posting of assertion response to MicrosoftOnline

One thing I’ve learned over the years about the engineering a Ping Identity is that their consistent approach to ensuring compliance is a boon. For example, posting an assertion over ws-fedp protocol back to Microsoft Online has the following form:

image

Using fiddler to spy on the https tunnel between PingFederate/browser and Microsoft

Let’s alter the SP (Microsoft Online) to now talk to different IDP, for the same realm name (rapmlsqa.info). The goal is to make our own IDP issue assertions. Then we can compare the form of our assertion on the wire with that above (assumed to be in really good compliance).

So, to make the RP make a request of our  own IDP, we re-configure 2 parameters (at the requesting party). These are the name of the IDP (expected in the response) and the address where to send the IDP a request (seeking the response…!).

image

if we look at the response our own IDP issues, its

image

Its obvious that we have 2 quite difference generations of ws-fedp profiling here; so its going to be hard to make some subtle compliance argument that interferes with interworking. And interworking problems there are (with our response): the browser intercept the message with its own UI.

Looking at the wire form of the message our IDP tries to relay through the browser, the main problem with IDP’s original response seems to be that it tries to post off the response to the NAME given by Microsoft Office for itself in its SP’s request; rather than posting it off to an address. And it just so happens that the name causes a certain UI behavior in “app” browsers.

The request doesn’t indicate the address:

image

which implies that the fix is to hardcode the address (For that name) into the IDPs logic  – or at least have some simple mapping from names to addresses.

Next, the issue seems to be that our assertion has no authentication Statement (even though the largely equivalent authorization Statement seems well formed – with the same value for assertion subject that Ping Federate issues in an Authentication Statement). Here we see how Microsoft biased its developers, since by default its WIF toolkits don’t produce …authentication Statements (and the simple knowhow on how to make them with WIF seems to be a national security secret– hoping to deny interworking except to a trusted few, while pretending the systems are open).

As I recall, all we have to do is add an authenticationInstant and a recognized AuthenticationMethod to the bag of claims of the token description, and the token formatter will do the rest (producing the desired Authentication Statement).

Posted in pingfederate, SAML

1980s Tempest shielding

image

http://www.jproc.ca/crypto/canadian_comm_center.html

shows the materials used in the tempest shielding around these data general 16bit 64k mini computers (and associated io units), doing late 1970s/early 1980s message switching of 9600 baud channels

Posted in early computing

ws-trust from Office 365 to Azure ACS UsernameToken endpoints

In an earlier post we documented how we learned about Azure ACS in the OAUTH context. Here we look at ws-trust, again, assuming that the Office 365 Federation Gateway wishes to authenticate the user of Outlook (a thick client).

In the OAUTH case we learned how our local web app code could create serviceprincipals in ACS using the ACS API; representing client vendors entitles to use the authorization and delegaion-record  management services of ACS. In the Outlook to Office 365 case, the same API mechanism will presumably enable us to populate user records as serviceprincipals with names and passwords (rather than OAUTH client-vendor with vendor-names and vendor-passwords).

If I have the protocol model right for office tenants using custom domains with federated authentication, the Office 365 Federation Gateway or outlook.com or Exchange Online (or something! in the weird and ultra-complex Office 365 hosting world)  will issue a server-serer ws-trust RST message to our ACS tenant’s endpoint. This request, over https, will bear a simple username token. Within is the username and password collected earlier by Outlook and supplied to the Office 365 world that turns around and issues the ws-trust request mentioned above – seeking the help of ACS to “Verify” the values.

http://msdn.microsoft.com/en-us/library/windowsazure/gg185954.aspx seems to show use what to do.

Presumably, the token issued would be SAML1, for compatibility with Office 365. One would NOT bother with the AC configuration of the Relying Party that sets up encryption of the token. The audience name (RP name) for Office would presumably be urn:federation:MicrosoftOnline. For demo purposes, 3 constant values for the 3 required attributes (UPN, ImmutableID, SAML_NAME=UPN) could be supplied. Obviously, one would also run the set-msoldomainfederationsettings command on the Federation Gateway (office 365 tenant) point to the ACS endpoints and mex metadata endpoint (rather than ADFS or PingFederate).

The biggest hurdle with doing this kind of things is usually the secureconversation stuff. I wonder if ACS is willing to expose a binding without insisting that the FederationGateway (microsoftOnline) performs secure conversation protocols (around the delivering the ws-trust RST). Alternatively, if the ACS metadata exposes the right secure conversation bindings, perhaps the Federation Gateway will just perform secure conversation, too.

It seems worth a try – if only to get our brains back into gear on writing a modern, dotnet4.5-era usernametoken-capable ws-trust endpoint hosted by IIS8.

Now, lets go back in time and use the tools that were assumed by the evangelism team. (This is important, since IIS versions, IIS security models, IIS scripts don’t tend from the WIF team don’t tend to be forward compatible; so use the environment they assumed, if you want to keep some hair.)

image

Posted in office365

plateaued functions

image

image

image

the previous memo plus the above enables us to see what Turing was saying (in a more sensitive way):

image

http://turingarchive.org/viewer/?id=133&title=29

H/H1 is a cyclic group, giving the desired trace function.

“following a long gap”… I wonder why!

image

http://www.minsocam.org/ammin/AM57/AM57_255.pdf

Posted in coding theory

derivations of boolean functions; cryptanalysis defense; Zariski tangents

image

http://qchu.wordpress.com/2011/02/26/the-quaternions-and-lie-algebras-i/#comment-3341

gives us several examples:-

basic:

image

rotation:

image

complex

image

Heisenberg

image

http://qchu.wordpress.com/2011/02/26/the-quaternions-and-lie-algebras-i/

The material nicely characterizes how folks thought, in the 1930s.

Consider now the  defense against “cryptanalysis of the cryptologic” (to use NSA’isms):

image

image

One sees the motivation for the (optional) non-linearity of the s-boxes – applicable when one faces the “probabilistic version” of the attack.

image

image

generalizing the theory led to:

image

http://qchu.wordpress.com/2011/02/26/the-quaternions-and-lie-algebras-i/

Of course, we recall:

image

image

Given the probalistic nature of quantum mechanics and the “probalistic” (i.e. sum/product decoding) attack on s-boxes, it makes some sense that Turing considered quaternion algebras when:

image

image

http://qchu.wordpress.com/2011/06/14/the-quaternions-and-lie-algebras-ii/

Posted in coding theory