Search Results

Search found 409 results on 17 pages for 'your displayname here!'.

Page 2/17 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • WIF, ADFS 2 and WCF&ndash;Part 4: Service Client (using Service Metadata)

    - by Your DisplayName here!
    See parts 1, 2 and 3 first. In this part we will finally build a client for our federated service. There are basically two ways to accomplish this. You can use the WCF built-in tooling to generate client and configuration via the service metadata (aka ‘Add Service Reference’). This requires no WIF on the client side. Another approach would be to use WIF’s WSTrustChannelFactory to manually talk to the ADFS 2 WS-Trust endpoints. This option gives you more flexibility, but is slightly more code to write. You also need WIF on the client which implies that you need to run on a WIF supported operating system – this rules out e.g. Windows XP clients. We’ll start with the metadata way. You simply create a new client project (e.g. a console app) – call ‘Add Service Reference’ and point the dialog to your service endpoint. What will happen then is, that VS will contact your service and read its metadata. Inside there is also a link to the metadata endpoint of ADFS 2. This one will be contacted next to find out which WS-Trust endpoints are available. The end result will be a client side proxy and a configuration file. Let’s first write some code to call the service and then have a closer look at the config file. var proxy = new ServiceClient(); proxy.GetClaims().ForEach(c =>     Console.WriteLine("{0}\n {1}\n  {2} ({3})\n",         c.ClaimType,         c.Value,         c.Issuer,         c.OriginalIssuer)); That’s all. The magic is happening in the configuration file. When you in inspect app.config, you can see the following general configuration hierarchy: <client /> element with service endpoint information federation binding and configuration containing ADFS 2 endpoint 1 (with binding and configuration) ADFS 2 endpoint n (with binding and configuration) (where ADFS 2 endpoint 1…n are the endpoints I talked about in part 1) You will see a number of <issuer /> elements in the binding configuration where simply the first endpoint from the ADFS 2 metadata becomes the default endpoint and all other endpoints and their configuration are commented out. You now need to find the endpoint you want to use (based on trust version, credential type and security mode) and replace that with the default endpoint. That’s it. When you call the WCF proxy, it will inspect configuration, then first contact the selected ADFS 2 endpoint to request a token. This token will then be used to authenticate against the service. In the next post I will show you the more manual approach using the WIF APIs.

    Read the article

  • Windows Azure Root CAs and SSL Client Certificates

    - by Your DisplayName here!
    I ran into some problems while trying to make SSL client certificates work for StarterSTS 1.5. In theory you have to do two things (via startup tasks): Unlock the SSL section in IIS Install all the root certificates for the client certs you want to accept I did that. But it still does not work. While inspecting the event log, I stumbled over an schannel error message that I’ve never seen before: “When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.” WTF? And indeed standard Azure (web role) VMs trust 275 root CAs (see attached list). Including kinda obscure ones. I don’t really know why MS made this design decision. It seems just wrong (including breaking the SSL client cert functionality). Deleting like 60% of them made SSL client certs from my CA work. So I guess I now have to find an automated way to attach CTLs to my site…joy. Exported list of trusted CA (as of 30th Dec 2010) AC Raíz Certicámara S.A. (4/2/2030 9:42:02 PM) AC RAIZ FNMT-RCM (1/1/2030 12:00:00 AM) A-CERT ADVANCED (10/23/2011 2:14:14 PM) Actalis Authentication CA G1 (6/25/2022 2:06:00 PM) Agence Nationale de Certification Electronique (8/12/2037 9:03:17 AM) Agence Nationale de Certification Electronique (8/12/2037 9:58:14 AM) Agencia Catalana de Certificacio (NIF Q-0801176-I) (1/7/2031 10:59:59 PM) America Online Root Certification Authority 1 (11/19/2037 8:43:00 PM) America Online Root Certification Authority 2 (9/29/2037 2:08:00 PM) ANCERT Certificados CGN (2/11/2024 5:27:12 PM) ANCERT Certificados Notariales (2/11/2024 3:58:26 PM) ANCERT Corporaciones de Derecho Publico (2/11/2024 5:22:45 PM) A-Trust-nQual-01 (11/30/2014 11:00:00 PM) A-Trust-nQual-03 (8/17/2015 10:00:00 PM) A-Trust-Qual-01 (11/30/2014 11:00:00 PM) A-Trust-Qual-02 (12/2/2014 11:00:00 PM) A-Trust-Qual-03a (4/24/2018 10:00:00 PM) Austria Telekom-Control Kommission (9/24/2005 12:40:00 PM) Austrian Society for Data Protection (2/12/2009 11:30:30 AM) Austrian Society for Data Protection GLOBALTRUST Certification Service (9/18/2036 2:12:35 PM) Autoridad Certificadora Raiz de la Secretaria de Economia (5/9/2025 12:00:00 AM) Autoridad de Certificacion de la Abogacia (6/13/2030 10:00:00 PM) Autoridad de Certificacion Firmaprofesional CIF A62634068 (10/24/2013 10:00:00 PM) Autoridade Certificadora Raiz Brasileira (11/30/2011 11:59:00 PM) Baltimore CyberTrust Root (5/12/2025 11:59:00 PM) BIT AdminCA-CD-T01 (1/25/2016 12:36:19 PM) BIT Admin-Root-CA (11/10/2021 7:51:07 AM) Buypass Class 2 CA 1 (10/13/2016 10:25:09 AM) Buypass Class 3 CA 1 (5/9/2015 2:13:03 PM) CA Disig (3/22/2016 1:39:34 AM) CertEurope (3/27/2037 11:00:00 PM) CERTICAMARA S.A. (2/23/2015 5:10:37 PM) Certicámara S.A. (5/23/2011 10:00:00 PM) Certigna (6/29/2027 3:13:05 PM) Certipost E-Trust Primary Normalised CA (7/26/2020 10:00:00 AM) Certipost E-Trust Primary Qualified CA (7/26/2020 10:00:00 AM) Certipost E-Trust Primary TOP Root CA (7/26/2025 10:00:00 AM) Certisign Autoridade Certificadora AC1S (6/27/2018 12:00:00 AM) Certisign Autoridade Certificadora AC2 (6/27/2018 12:00:00 AM) Certisign Autoridade Certificadora AC3S (7/9/2018 8:56:32 PM) Certisign Autoridade Certificadora AC4 (6/27/2018 12:00:00 AM) CertPlus Class 1 Primary CA (7/6/2020 11:59:59 PM) CertPlus Class 2 Primary CA (7/6/2019 11:59:59 PM) CertPlus Class 3 Primary CA (7/6/2019 11:59:59 PM) CertPlus Class 3P Primary CA (7/6/2019 11:59:59 PM) CertPlus Class 3TS Primary CA (7/6/2019 11:59:59 PM) CertRSA01 (3/3/2010 2:59:59 PM) certSIGN Root CA (7/4/2031 5:20:04 PM) Certum (6/11/2027 10:46:39 AM) Certum Trusted Network CA (12/31/2029 12:07:37 PM) Chambers of Commerce Root - 2008 (7/31/2038 12:29:50 PM) Chambersign Chambers of Commerce Root (9/30/2037 4:13:44 PM) Chambersign Global Root (9/30/2037 4:14:18 PM) Chambersign Public Notary Root (9/30/2037 4:14:49 PM) Chunghwa Telecom Co. Ltd. (12/20/2034 2:31:27 AM) Cisco Systems (5/14/2029 8:25:42 PM) CNNIC Root (4/16/2027 7:09:14 AM) Common Policy (10/15/2027 4:08:00 PM) COMODO (12/31/2028 11:59:59 PM) COMODO (1/18/2038 11:59:59 PM) COMODO (12/31/2029 11:59:59 PM) ComSign Advanced Security CA (3/24/2029 9:55:55 PM) ComSign CA (3/19/2029 3:02:18 PM) ComSign Secured CA (3/16/2029 3:04:56 PM) Correo Uruguayo - Root CA (12/31/2030 2:59:59 AM) Cybertrust Global Root (12/15/2021 8:00:00 AM) DanID (2/11/2037 9:09:30 AM) DanID (4/5/2021 5:03:17 PM) Deutsche Telekom Root CA 2 (7/9/2019 11:59:00 PM) DigiCert (11/10/2031 12:00:00 AM) DigiCert (11/10/2031 12:00:00 AM) DigiCert (11/10/2031 12:00:00 AM) DigiNotar Root CA (3/31/2025 6:19:21 PM) DIRECCION GENERAL DE LA POLICIA (2/8/2036 10:59:59 PM) DST (ABA.ECOM) CA (7/9/2009 5:33:53 PM) DST (ANX Network) CA (12/9/2018 4:16:48 PM) DST (Baltimore EZ) CA (7/3/2009 7:56:53 PM) DST (National Retail Federation) RootCA (12/8/2008 4:14:16 PM) DST (United Parcel Service) RootCA (12/7/2008 12:25:46 AM) DST ACES CA X6 (11/20/2017 9:19:58 PM) DST Root CA X3 (9/30/2021 2:01:15 PM) DST RootCA X1 (11/28/2008 6:18:55 PM) DST RootCA X2 (11/27/2008 10:46:16 PM) DSTCA E1 (12/10/2018 6:40:23 PM) DSTCA E2 (12/9/2018 7:47:26 PM) DST-Entrust GTI CA (12/9/2018 12:32:24 AM) D-TRUST GmbH (5/16/2022 5:20:47 AM) D-TRUST GmbH (6/8/2012 11:47:46 AM) D-TRUST GmbH (5/16/2022 5:20:47 AM) EBG Elektronik Sertifika Hizmet Saglayicisi (8/14/2016 12:31:09 AM) E-Certchile (9/5/2028 7:39:41 PM) Echoworx Root CA2 (10/7/2030 10:49:13 AM) ECRaizEstado (6/23/2030 1:41:27 PM) EDICOM (4/13/2028 4:24:22 PM) E-GÜVEN Elektronik Sertifika Hizmet Saglayicisi (1/4/2017 11:32:48 AM) E-ME SSI (RCA) (5/19/2027 8:48:15 AM) Entrust (11/27/2026 8:53:42 PM) Entrust (5/25/2019 4:39:40 PM) Entrust.net (12/7/2030 5:55:54 PM) Equifax Secure eBusiness CA-1 (6/21/2020 4:00:00 AM) Equifax Secure eBusiness CA-2 (6/23/2019 12:14:45 PM) Equifax Secure Global eBusiness CA-1 (6/21/2020 4:00:00 AM) eSign Australia: eSign Imperito Primary Root CA (5/23/2012 11:59:59 PM) eSign Australia: Gatekeeper Root CA (5/23/2014 11:59:59 PM) eSign Australia: Primary Utility Root CA (5/23/2012 11:59:59 PM) Fabrica Nacional de Moneda y Timbre (3/18/2019 3:26:19 PM) GeoTrust (8/22/2018 4:41:51 PM) GeoTrust (7/16/2036 11:59:59 PM) GeoTrust Global CA (5/21/2022 4:00:00 AM) GeoTrust Global CA 2 (3/4/2019 5:00:00 AM) GeoTrust Primary Certification Authority - G2 (1/18/2038 11:59:59 PM) GeoTrust Primary Certification Authority - G3 (12/1/2037 11:59:59 PM) GeoTrust Universal CA (3/4/2029 5:00:00 AM) GeoTrust Universal CA 2 (3/4/2029 5:00:00 AM) Global Chambersign Root - 2008 (7/31/2038 12:31:40 PM) GlobalSign (1/28/2028 12:00:00 PM) GlobalSign (12/15/2021 8:00:00 AM) Go Daddy Class 2 Certification Authority (6/29/2034 5:06:20 PM) GTE CyberTrust Global Root (8/13/2018 11:59:00 PM) GTE CyberTrust Root (4/3/2004 11:59:00 PM) GTE CyberTrust Root (2/23/2006 11:59:00 PM) Halcom CA FO (6/5/2020 10:33:31 AM) Halcom CA PO 2 (2/7/2019 6:33:31 PM) Hongkong Post Root CA (1/16/2010 11:59:00 PM) Hongkong Post Root CA 1 (5/15/2023 4:52:29 AM) I.CA První certifikacní autorita a.s. (4/1/2018 12:00:00 AM) I.CA První certifikacní autorita a.s. (4/1/2018 12:00:00 AM) InfoNotary (3/6/2026 5:33:05 PM) IPS SERVIDORES (12/29/2009 11:21:07 PM) IZENPE S.A. (1/30/2018 11:00:00 PM) Izenpe.com (12/13/2037 8:27:25 AM) Japan Certification Services, Inc. SecureSign RootCA1 (9/15/2020 2:59:59 PM) Japan Certification Services, Inc. SecureSign RootCA11 (4/8/2029 4:56:47 AM) Japan Certification Services, Inc. SecureSign RootCA2 (9/15/2020 2:59:59 PM) Japan Certification Services, Inc. SecureSign RootCA3 (9/15/2020 2:59:59 PM) Japan Local Government PKI Application CA (3/31/2016 2:59:59 PM) Japanese Government ApplicationCA (12/12/2017 3:00:00 PM) Juur-SK AS Sertifitseerimiskeskus (8/26/2016 2:23:01 PM) KamuSM (8/21/2017 11:37:07 AM) KISA RootCA 1 (8/24/2025 8:05:46 AM) KISA RootCA 3 (11/19/2014 6:39:51 AM) Macao Post eSignTrust (1/29/2013 11:59:59 PM) MicroSec e-Szigno Root CA (4/6/2017 12:28:44 PM) Microsoft Authenticode(tm) Root (12/31/1999 11:59:59 PM) Microsoft Root Authority (12/31/2020 7:00:00 AM) Microsoft Root Certificate Authority (5/9/2021 11:28:13 PM) Microsoft Timestamp Root (12/30/1999 11:59:59 PM) MOGAHA Govt of Korea (4/21/2012 9:07:23 AM) MOGAHA Govt of Korea GPKI (3/15/2017 6:00:04 AM) NetLock Arany (Class Gold) Fotanúsítvány (12/6/2028 3:08:21 PM) NetLock Expressz (Class C) Tanusitvanykiado (2/20/2019 2:08:11 PM) NetLock Kozjegyzoi (Class A) Tanusitvanykiado (2/19/2019 11:14:47 PM) NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado (12/15/2022 1:47:11 AM) NetLock Platina (Class Platinum) Fotanúsítvány (12/6/2028 3:12:44 PM) NetLock Uzleti (Class B) Tanusitvanykiado (2/20/2019 2:10:22 PM) Netrust CA1 (3/30/2021 2:57:45 AM) Network Solutions (12/31/2029 11:59:59 PM) NLB Nova Ljubljanska Banka d.d. Ljubljana (5/15/2023 12:22:45 PM) OISTE WISeKey Global Root GA CA (12/11/2037 4:09:51 PM) Post.Trust Root CA (7/5/2022 9:12:33 AM) Post.Trust Root CA (8/20/2010 1:56:21 PM) Posta CA Root (10/20/2028 12:52:08 PM) POSTarCA (2/7/2023 11:06:58 AM) QuoVadis Root CA 2 (11/24/2031 6:23:33 PM) QuoVadis Root CA 3 (11/24/2031 7:06:44 PM) QuoVadis Root Certification Authority (3/17/2021 6:33:33 PM) Root CA Generalitat Valenciana (7/1/2021 3:22:47 PM) RSA Security 2048 V3 (2/22/2026 8:39:23 PM) SECOM Trust Systems CO LTD (6/6/2037 2:12:32 AM) SECOM Trust Systems CO LTD (6/25/2019 10:23:48 PM) SECOM Trust Systems CO LTD (9/30/2023 4:20:49 AM) Secretaria de Economia Mexico (5/8/2025 12:00:00 AM) Secrétariat Général de la Défense Nationale (10/17/2020 2:29:22 PM) SecureNet CA Class B (10/16/2009 9:59:00 AM) Serasa Certificate Authority I (11/21/2024 2:12:45 PM) Serasa Certificate Authority II (11/21/2024 12:44:48 PM) Serasa Certificate Authority III (11/21/2024 1:24:14 PM) SERVICIOS DE CERTIFICACION - A.N.C. (3/9/2009 9:08:07 PM) Sigen-CA (6/29/2021 9:57:46 PM) Sigov-CA (1/10/2021 2:22:52 PM) Skaitmeninio sertifikavimo centras (12/28/2026 12:05:04 PM) Skaitmeninio sertifikavimo centras (12/25/2026 12:08:26 PM) Skaitmeninio sertifikavimo centras (12/22/2026 12:11:30 PM) Sonera Class1 CA (4/6/2021 10:49:13 AM) Sonera Class2 CA (4/6/2021 7:29:40 AM) Spanish Property & Commerce Registry CA (4/27/2012 9:39:50 AM) Staat der Nederlanden Root CA (12/16/2015 9:15:38 AM) Staat der Nederlanden Root CA - G2 (3/25/2020 11:03:10 AM) Starfield Class 2 Certification Authority (6/29/2034 5:39:16 PM) Starfield Technologies (6/26/2019 12:19:54 AM) Starfield Technologies Inc. (12/31/2029 11:59:59 PM) StartCom Certification Authority (9/17/2036 7:46:36 PM) S-TRUST Authentication and Encryption Root CA 2005:PN (6/21/2030 11:59:59 PM) Swisscom Root CA 1 (8/18/2025 10:06:20 PM) SwissSign (10/25/2036 8:30:35 AM) SwissSign Platinum G2 Root CA (10/25/2036 8:36:00 AM) SwissSign Silver G2 Root CA (10/25/2036 8:32:46 AM) TC TrustCenter Class 1 CA (1/1/2011 11:59:59 AM) TC TrustCenter Class 2 CA (1/1/2011 11:59:59 AM) TC TrustCenter Class 2 CA II (12/31/2025 10:59:59 PM) TC TrustCenter Class 3 CA (1/1/2011 11:59:59 AM) TC TrustCenter Class 3 CA II (12/31/2025 10:59:59 PM) TC TrustCenter Class 4 CA (1/1/2011 11:59:59 AM) TC TrustCenter Class 4 CA II (12/31/2025 10:59:59 PM) TC TrustCenter Time Stamping CA (1/1/2011 11:59:59 AM) TC TrustCenter Universal CA I (12/31/2025 10:59:59 PM) TC TrustCenter Universal CA II (12/31/2030 10:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte (7/16/2036 11:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte (12/31/2020 11:59:59 PM) thawte Primary Root CA - G2 (1/18/2038 11:59:59 PM) thawte Primary Root CA - G3 (12/1/2037 11:59:59 PM) Thawte Timestamping CA (12/31/2020 11:59:59 PM) Trustis EVS Root CA (1/9/2027 11:56:00 AM) Trustis FPS Root CA (1/21/2024 11:36:54 AM) Trustwave (1/1/2035 5:37:19 AM) Trustwave (12/31/2029 7:40:55 PM) Trustwave (12/31/2029 7:52:06 PM) TURKTRUST Elektronik Islem Hizmetleri (9/16/2015 12:13:05 PM) TURKTRUST Elektronik Islem Hizmetleri (3/22/2015 10:04:51 AM) TURKTRUST Elektronik Sertifika Hizmet Saglayicisi (9/16/2015 10:07:57 AM) TURKTRUST Elektronik Sertifika Hizmet Saglayicisi (3/22/2015 10:27:17 AM) TÜRKTRUST Elektronik Sertifika Hizmet Saglayicisi (12/22/2017 6:37:19 PM) TW Government Root Certification Authority (12/5/2032 1:23:33 PM) TWCA Root Certification Authority 1 (12/31/2030 3:59:59 PM) TWCA Root Certification Authority 2 (12/31/2030 3:59:59 PM) U.S. Government FBCA (10/6/2010 6:53:56 PM) UCA Global Root (12/31/2037 12:00:00 AM) UCA Root (12/31/2029 12:00:00 AM) USERTrust (7/9/2019 6:40:36 PM) USERTrust (7/9/2019 5:36:58 PM) USERTrust (6/24/2019 7:06:30 PM) USERTrust (7/9/2019 6:19:22 PM) USERTrust (5/30/2020 10:48:38 AM) UTN - USERFirst-Network Applications (7/9/2019 6:57:49 PM) ValiCert Class 3 Policy Validation Authority (6/26/2019 12:22:33 AM) VAS Latvijas Pasts SSI(RCA) (9/13/2024 9:27:57 AM) VeriSign (5/18/2018 11:59:59 PM) VeriSign (7/16/2036 11:59:59 PM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (12/31/1999 9:37:48 AM) VeriSign (1/7/2004 11:59:59 PM) VeriSign (5/18/2018 11:59:59 PM) VeriSign (1/7/2004 11:59:59 PM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (1/7/2020 11:59:59 PM) VeriSign (12/31/1999 9:35:58 AM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (7/16/2036 11:59:59 PM) VeriSign (1/7/2004 11:59:59 PM) VeriSign (7/16/2036 11:59:59 PM) VeriSign (1/7/2010 11:59:59 PM) VeriSign (5/18/2018 11:59:59 PM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (1/7/2004 11:59:59 PM) VeriSign (7/16/2036 11:59:59 PM) VeriSign (7/16/2036 11:59:59 PM) VeriSign (8/1/2028 11:59:59 PM) VeriSign (5/18/2018 11:59:59 PM) VeriSign Class 3 Public Primary CA (8/1/2028 11:59:59 PM) VeriSign Class 3 Public Primary Certification Authority - G4 (1/18/2038 11:59:59 PM) VeriSign Time Stamping CA (1/7/2004 11:59:59 PM) VeriSign Universal Root Certification Authority (12/1/2037 11:59:59 PM) Visa eCommerce Root (6/24/2022 12:16:12 AM) Visa Information Delivery Root CA (6/29/2025 5:42:42 PM) VRK Gov. Root CA (12/18/2023 1:51:08 PM) Wells Fargo Root Certificate Authority (1/14/2021 4:41:28 PM) WellsSecure Public Certificate Authority (12/14/2022 12:07:54 AM) Xcert EZ by DST (7/11/2009 4:14:18 PM)

    Read the article

  • Token based Authentication for WCF HTTP/REST Services: Authorization

    - by Your DisplayName here!
    In the previous post I showed how token based authentication can be implemented for WCF HTTP based services. Authentication is the process of finding out who the user is – this includes anonymous users. Then it is up to the service to decide under which circumstances the client has access to the service as a whole or individual operations. This is called authorization. By default – my framework does not allow anonymous users and will deny access right in the service authorization manager. You can however turn anonymous access on – that means technically, that instead of denying access, an anonymous principal is placed on Thread.CurrentPrincipal. You can flip that switch in the configuration class that you can pass into the service host/factory. var configuration = new WebTokenWebServiceHostConfiguration {     AllowAnonymousAccess = true }; But this is not enough, in addition you also need to decorate the individual operations to allow anonymous access as well, e.g.: [AllowAnonymousAccess] public string GetInfo() {     ... } Inside these operations you might have an authenticated or an anonymous principal on Thread.CurrentPrincipal, and it is up to your code to decide what to do. Side note: Being a security guy, I like this opt-in approach to anonymous access much better that all those opt-out approaches out there (like the Authorize attribute – or this.). Claims-based Authorization Since there is a ClaimsPrincipal available, you can use the standard WIF claims authorization manager infrastructure – either declaratively via ClaimsPrincipalPermission or programmatically (see also here). [ClaimsPrincipalPermission(SecurityAction.Demand,     Resource = "Claims",     Operation = "View")] public ViewClaims GetClientIdentity() {     return new ServiceLogic().GetClaims(); }   In addition you can also turn off per-request authorization (see here for background) via the config and just use the “domain specific” instrumentation. While the code is not 100% done – you can download the current solution here. HTH (Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)

    Read the article

  • What I don&rsquo;t like about WIF&rsquo;s Claims-based Authorization

    - by Your DisplayName here!
    In my last post I wrote about what I like about WIF’s proposed approach to authorization – I also said that I definitely would build upon that infrastructure for my own systems. But implementing such a system is a little harder as it could be. Here’s why (and that’s purely my perspective): First of all WIF’s authorization comes in two “modes” Per-request authorization. When an ASP.NET/WCF request comes in, the registered authorization manager gets called. For SOAP the SOAP action gets passed in. For HTTP requests (ASP.NET, WCF REST) the URL and verb. Imperative authorization This happens when you explicitly call the claims authorization API from within your code. There you have full control over the values for action and resource. In ASP.NET per-request authorization is optional (depends on if you have added the ClaimsAuthorizationHttpModule). In WCF you always get the per-request checks as soon as you register the authorization manager in configuration. I personally prefer the imperative authorization because first of all I don’t believe in URL based authorization. Especially in the times of MVC and routing tables, URLs can be easily changed – but then you also have to adjust your authorization logic every time. Also – you typically need more knowledge than a simple “if user x is allowed to invoke operation x”. One problem I have is, both the per-request calls as well as the standard WIF imperative authorization APIs wrap actions and resources in the same claim type. This makes it hard to distinguish between the two authorization modes in your authorization manager. But you typically need that feature to structure your authorization policy evaluation in a clean way. The second problem (which is somehow related to the first one) is the standard API for interacting with the claims authorization manager. The API comes as an attribute (ClaimsPrincipalPermissionAttribute) as well as a class to use programmatically (ClaimsPrincipalPermission). Both only allow to pass in simple strings (which results in the wrapping with standard claim types mentioned earlier). Both throw a SecurityException when the check fails. The attribute is a code access permission attribute (like PrincipalPermission). That means it will always be invoked regardless how you call the code. This may be exactly what you want, or not. In a unit testing situation (like an MVC controller) you typically want to test the logic in the function – not the security check. The good news is, the WIF API is flexible enough that you can build your own infrastructure around their core. For my own projects I implemented the following extensions: A way to invoke the registered claims authorization manager with more overloads, e.g. with different claim types or a complete AuthorizationContext. A new CAS attribute (with the same calling semantics as the built-in one) with custom claim types. A MVC authorization attribute with custom claim types. A way to use branching – as opposed to catching a SecurityException. I will post the code for these various extensions here – so stay tuned.

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 2

    - by Your DisplayName here!
    In the last post I showed you how to take control over the invocation of ClaimsAuthorizationManager. Then you have complete freedom over the claim types, the amount of claims and the values. In addition I added two attributes that invoke the authorization manager using an “application claim type”. This way it is very easy to distinguish between authorization calls that originate from WIF’s per-request authorization and the ones from “within” you application. The attribute comes in two flavours: a CAS attribute (invoked by the CLR) and an ASP.NET MVC attribute (for MVC controllers, invoke by the MVC plumbing). Both also feature static methods to easily call them using the application claim types. The CAS attribute is part of Thinktecture.IdentityModel on Codeplex (or via NuGet: Install-Package Thinktecture.IdentityModel). If you really want to see that code ;) There is also a sample included in the Codeplex donwload. The MVC attribute is currently used in Thinktecture.IdentityServer – and I don’t currently plan to make it part of the library project since I don’t want to add a dependency on MVC for now. You can find the code below – and I will write about its usage in a follow-up post. public class ClaimsAuthorize : AuthorizeAttribute {     private string _resource;     private string _action;     private string[] _additionalResources;     /// <summary>     /// Default action claim type.     /// </summary>     public const string ActionType = "http://application/claims/authorization/action";     /// <summary>     /// Default resource claim type     /// </summary>     public const string ResourceType = "http://application/claims/authorization/resource";     /// <summary>     /// Additional resource claim type     /// </summary>     public const string AdditionalResourceType = "http://application/claims/authorization/additionalresource"          public ClaimsAuthorize(string action, string resource, params string[] additionalResources)     {         _action = action;         _resource = resource;         _additionalResources = additionalResources;     }     public static bool CheckAccess(       string action, string resource, params string[] additionalResources)     {         return CheckAccess(             Thread.CurrentPrincipal as IClaimsPrincipal,             action,             resource,             additionalResources);     }     public static bool CheckAccess(       IClaimsPrincipal principal, string action, string resource, params string[] additionalResources)     {         var context = CreateAuthorizationContext(             principal,             action,             resource,             additionalResources);         return ClaimsAuthorization.CheckAccess(context);     }     protected override bool AuthorizeCore(HttpContextBase httpContext)     {         return CheckAccess(_action, _resource, _additionalResources);     }     private static WIF.AuthorizationContext CreateAuthorizationContext(       IClaimsPrincipal principal, string action, string resource, params string[] additionalResources)     {         var actionClaims = new Collection<Claim>         {             new Claim(ActionType, action)         };         var resourceClaims = new Collection<Claim>         {             new Claim(ResourceType, resource)         };         if (additionalResources != null && additionalResources.Length > 0)         {             additionalResources.ToList().ForEach(ar => resourceClaims.Add(               new Claim(AdditionalResourceType, ar)));         }         return new WIF.AuthorizationContext(             principal,             resourceClaims,             actionClaims);     } }

    Read the article

  • Thinktecture.IdentityModel: WIF Support for WCF REST Services and OData

    - by Your DisplayName here!
    The latest drop of Thinktecture.IdentityModel includes plumbing and support for WIF, claims and tokens for WCF REST services and Data Services (aka OData). Cibrax has an alternative implementation that uses the WCF Rest Starter Kit. His recent post reminded me that I should finally “document” that part of our library. Features include: generic plumbing for all WebServiceHost derived WCF services support for SAML and SWT tokens support for ClaimsAuthenticationManager and ClaimsAuthorizationManager based solely on native WCF extensibility points (and WIF) This post walks you through the setup of an OData / WCF DataServices endpoint with token authentication and claims support. This sample is also included in the codeplex download along a similar sample for plain WCF REST services. Setting up the Data Service To prove the point I have created a simple WCF Data Service that renders the claims of the current client as an OData set. public class ClaimsData {     public IQueryable<ViewClaim> Claims     {         get { return GetClaims().AsQueryable(); }     }       private List<ViewClaim> GetClaims()     {         var claims = new List<ViewClaim>();         var identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;           int id = 0;         identity.Claims.ToList().ForEach(claim =>             {                 claims.Add(new ViewClaim                 {                    Id = ++id,                    ClaimType = claim.ClaimType,                    Value = claim.Value,                    Issuer = claim.Issuer                 });             });           return claims;     } } …and hooked that up with a read only data service: public class ClaimsDataService : DataService<ClaimsData> {     public static void InitializeService(IDataServiceConfiguration config)     {         config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);     } } Enabling WIF Before you enable WIF, you should generate your client proxies. Afterwards the service will only accept requests with an access token – and svcutil does not support that. All the WIF magic is done in a special service authorization manager called the FederatedWebServiceAuthorizationManager. This code checks incoming calls to see if the Authorization HTTP header (or X-Authorization for environments where you are not allowed to set the authorization header) contains a token. This header must either start with SAML access_token= or WRAP access_token= (for SAML or SWT tokens respectively). For SAML validation, the plumbing uses the normal WIF configuration. For SWT you can either pass in a SimpleWebTokenRequirement or the SwtIssuer, SwtAudience and SwtSigningKey app settings are checked.If the token can be successfully validated, ClaimsAuthenticationManager and ClaimsAuthorizationManager are invoked and the IClaimsPrincipal gets established. The service authorization manager gets wired up by the FederatedWebServiceHostFactory: public class FederatedWebServiceHostFactory : WebServiceHostFactory {     protected override ServiceHost CreateServiceHost(       Type serviceType, Uri[] baseAddresses)     {         var host = base.CreateServiceHost(serviceType, baseAddresses);           host.Authorization.ServiceAuthorizationManager =           new FederatedWebServiceAuthorizationManager();         host.Authorization.PrincipalPermissionMode = PrincipalPermissionMode.Custom;           return host;     } } The last step is to set up the .svc file to use the service host factory (see the sample download). Calling the Service To call the service you need to somehow get a token. This is up to you. You can either use WSTrustChannelFactory (for the full CLR), WSTrustClient (Silverlight) or some other way to obtain a token. The sample also includes code to generate SWT tokens for testing – but the whole WRAP/SWT support will be subject of a separate post. I created some extensions methods for the most common web clients (WebClient, HttpWebRequest, DataServiceContext) that allow easy setting of the token, e.g.: public static void SetAccessToken(this DataServiceContext context,   string token, string type, string headerName) {     context.SendingRequest += (s, e) =>     {         e.RequestHeaders[headerName] = GetHeader(token, type);     }; } Making a query against the Data Service could look like this: static void CallService(string token, string type) {     var data = new ClaimsData(new Uri("https://server/odata.svc/"));     data.SetAccessToken(token, type);       data.Claims.ToList().ForEach(c =>         Console.WriteLine("{0}\n {1}\n ({2})\n", c.ClaimType, c.Value, c.Issuer)); } HTH

    Read the article

  • TechDays 2011 Sweden Videos

    - by Your DisplayName here!
    All the videos from the excellent Örebro event are now online. Dominick Baier: A Technical Introduction to the Windows Identity Foundation (watch) Dominick Baier & Christian Weyer: Securing REST-Services and Web APIs on the Windows Azure Platform (watch) Christian Weyer: Real World Azure - Elasticity from on-premise to the cloud and back (watch) Our interview with Robert (watch)

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 3 (Usage)

    - by Your DisplayName here!
    In the previous posts I showed off some of the additions I made to WIF’s authorization infrastructure. I now want to show some samples how I actually use these extensions. The following code snippets are from Thinktecture.IdentityServer on Codeplex. The following shows the MVC attribute on the WS-Federation controller: [ClaimsAuthorize(Constants.Actions.Issue, Constants.Resources.WSFederation)] public class WSFederationController : Controller or… [ClaimsAuthorize(Constants.Actions.Administration, Constants.Resources.RelyingParty)] public class RelyingPartiesAdminController : Controller In other places I used the imperative approach (e.g. the WRAP endpoint): if (!ClaimsAuthorize.CheckAccess(principal, Constants.Actions.Issue, Constants.Resources.WRAP)) {     Tracing.Error("User not authorized");     return new UnauthorizedResult("WRAP", true); } For the WCF WS-Trust endpoints I decided to use the per-request approach since the SOAP actions are well defined here. The corresponding authorization manager roughly looks like this: public class AuthorizationManager : ClaimsAuthorizationManager {     public override bool CheckAccess(AuthorizationContext context)     {         var action = context.Action.First();         var id = context.Principal.Identities.First();         // if application authorization request         if (action.ClaimType.Equals(ClaimsAuthorize.ActionType))         {             return AuthorizeCore(action, context.Resource, context.Principal.Identity as IClaimsIdentity);         }         // if ws-trust issue request         if (action.Value.Equals(WSTrust13Constants.Actions.Issue))         {             return AuthorizeTokenIssuance(new Collection<Claim> { new Claim(ClaimsAuthorize.ResourceType, Constants.Resources.WSTrust) }, id);         }         return base.CheckAccess(context);     } } You see that it is really easy now to distinguish between per-request and application authorization which makes the overall design much easier. HTH

    Read the article

  • Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)

    - by Your DisplayName here!
    Delegation using the ActAs approach has some interesting security features A security token service can make authorization and validation checks before issuing the ActAs token. Combined with proof keys you get non-repudiation features. The ultimate receiver sees the original caller as direct caller and can optionally traverse the delegation chain. Encryption and audience restriction can be tied down Most samples out there (including the SDK sample) use the CreateChannelActingAs extension method from WIF to request ActAs tokens. This method builds on top of the WCF binding configuration which may not always be suitable for your situation. You can also use the WSTrustChannel to request ActAs tokens. This allows direct and programmatic control over bindings and configuration and is my preferred approach. The below method requests an ActAs token based on a bootstrap token. The returned token can then directly be used with the CreateChannelWithIssued token extension method. private SecurityToken GetActAsToken(SecurityToken bootstrapToken) {     var factory = new WSTrustChannelFactory(         new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),         new EndpointAddress(_stsAddress));     factory.TrustVersion = TrustVersion.WSTrust13;     factory.Credentials.UserName.UserName = "middletier";     factory.Credentials.UserName.Password = "abc!123";     var rst = new RequestSecurityToken     {         AppliesTo = new EndpointAddress(_serviceAddress),         RequestType = RequestTypes.Issue,         KeyType = KeyTypes.Symmetric,         ActAs = new SecurityTokenElement(bootstrapToken)     };     var channel = factory.CreateChannel();     var delegationToken = channel.Issue(rst);     return delegationToken; }   HTH

    Read the article

  • Windows Security Videos auf Channel 9

    - by Your DisplayName here!
    Ich habe vor ein paar Wochen mit Lori drei Videos zum Thema Windows Security für Entwickler aufgenommen – die sind nun Online. Der erste Teil beschäftigt sich mit den absoluten Grundlagen der Windows Sicherheit. Was ist ein Konto? Was ist eine SID? Was ist ein Windows Token? Weiterhin wird gezeigt, wie sich diese grundlegenden Windows Einrichtungen über Managed Code anprogrammieren lassen. Der Vortrag endet mit einem kleinen Einblick in die Vorgehensweise von UAC, und wie dieses programmatisch verwendet werden kann. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-1 Teil zwei beschäfitgt sich mit Zugriffs-Kontrolllisten, und wie diese mit .NET Code gelesen und geschrieben werden können. Weiterhin werden die beiden verwandten Konzepte Logon Session und Impersonierung besprochen. Beide Einrichtungen erzeugen einen neuen Token, sind aber grundlegend verschieden in ihren Einsatzgebieten. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-2 Teil drei stellt das Kerberos Netzwerk-Authentifizierungsprotokoll vor. Da dieses Protokoll standardmäßig in Active Directory verwendet wird, sollten man es in den Grundzügen kennen. Natürlich kann auch Kerberos aus Managed Code verwendet werden – die abschließende Demo zeigt wie dies funktioniert. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-3 …und noch ein kleines Interview http://channel9.msdn.com/Blogs/Lori/Interview-mit-Dominick-Baier Viel Spaß ;)

    Read the article

  • What I like about WIF&rsquo;s Claims-based Authorization

    - by Your DisplayName here!
    In “traditional” .NET with its IPrincipal interface and IsInRole method, developers were encouraged to write code like this: public void AddCustomer(Customer customer) {     if (Thread.CurrentPrincipal.IsInRole("Sales"))     {         // add customer     } } In code reviews I’ve seen tons of code like this. What I don’t like about this is, that two concerns in your application get tightly coupled: business and security logic. But what happens when the security requirements change – and they will (e.g. members of the sales role and some other people from different roles need to create customers)? Well – since your security logic is sprinkled across your project you need to change the security checks in all relevant places (and make sure you don’t forget one) and you need to re-test, re-stage and re-deploy the complete app. This is clearly not what we want. WIF’s claims-based authorization encourages developers to separate business code and authorization policy evaluation. This is a good thing. So the same security check with WIF’s out-of-the box APIs would look like this: public void AddCustomer(Customer customer) {     try     {         ClaimsPrincipalPermission.CheckAccess("Customer", "Add");           // add customer     }     catch (SecurityException ex)     {         // access denied     } } You notice the fundamental difference? The security check only describes what the code is doing (represented by a resource/action pair) – and does not state who is allowed to invoke the code. As I mentioned earlier – the who is most probably changing over time – the what most probably not. The call to ClaimsPrincipalPermission hands off to another class called the ClaimsAuthorizationManager. This class handles the evaluation of your security policy and is ideally in a separate assembly to allow updating the security logic independently from the application logic (and vice versa). The claims authorization manager features a method called CheckAccess that retrieves three values (wrapped inside an AuthorizationContext instance) – action (“add”), resource (“customer”) and the principal (including its claims) in question. CheckAccess then evaluates those three values and returns true/false. I really like the separation of concerns part here. Unfortunately there is not much support from Microsoft beyond that point. And without further tooling and abstractions the CheckAccess method quickly becomes *very* complex. But still I think that is the way to go. In the next post I will tell you what I don’t like about it (and how to fix it).

    Read the article

  • Access Control Service: Passive/Active Transition Sample

    - by Your DisplayName here!
    Here you can find my updated ACS2 sample. In addition to the existing front ends (web [WS-Federation], console [SOAP & REST], Silverlight [REST]) and error handling, it now also includes a WPF client that shows the passive/active transition with a SOAP service as illustrated here. All the ACS interaction is encapsulated in a WPF user control that: retrieves the JSON feed displays a list of supported identity providers triggers the sign in via a browser control retrieves the token response packages the token as a GenericXmlSecurityToken (to be used directly with the WIF ChannelFactory extensions methods) All you need to supply is the ACS namespace and the realm. Have fun!

    Read the article

  • Token based Authentication for WCF HTTP/REST Services: The Client

    - by Your DisplayName here!
    If you wondered how a client would have to look like to work with the authentication framework, it is pretty straightfoward: Request a token Put that token on the authorization header (along with a registered scheme) and make the service call e.g.: var oauth2 = new OAuth2Client(_oauth2Address); var swt = oauth2.RequestAccessToken( "username", "password", _baseAddress.AbsoluteUri);   var client = new HttpClient { BaseAddress = _baseAddress }; client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", swt); var response = client.Get("identity"); response.EnsureSuccessStatusCode(); HTH

    Read the article

  • Thinktecture.IdentityModel: Comparing Strings without leaking Timinig Information

    - by Your DisplayName here!
    Paul Hill commented on a recent post where I was comparing HMACSHA256 signatures. In a nutshell his complaint was that I am leaking timing information while doing so – or in other words, my code returned faster with wrong (or partially wrong) signatures than with the correct signature. This can be potentially used for timing attacks like this one. I think he got a point here, especially in the era of cloud computing where you can potentially run attack code on the same physical machine as your target to do high resolution timing analysis (see here for an example). It turns out that it is not that easy to write a time-constant string comparer due to all sort of (unexpected) clever optimization mechanisms in the CLR. With the help and feedback of Paul and Shawn I came up with this: Structure the code in a way that the CLR will not try to optimize it In addition turn off optimization (just in case a future version will come up with new optimization methods) Add a random sleep when the comparison fails (using Shawn’s and Stephen’s nice Random wrapper for RNGCryptoServiceProvider). You can find the full code in the Thinktecture.IdentityModel download. [MethodImpl(MethodImplOptions.NoOptimization)] public static bool IsEqual(string s1, string s2) {     if (s1 == null && s2 == null)     {         return true;     }       if (s1 == null || s2 == null)     {         return false;     }       if (s1.Length != s2.Length)     {         return false;     }       var s1chars = s1.ToCharArray();     var s2chars = s2.ToCharArray();       int hits = 0;     for (int i = 0; i < s1.Length; i++)     {         if (s1chars[i].Equals(s2chars[i]))         {             hits += 2;         }         else         {             hits += 1;         }     }       bool same = (hits == s1.Length * 2);       if (!same)     {         var rnd = new CryptoRandom();         Thread.Sleep(rnd.Next(0, 10));     }       return same; }

    Read the article

  • ASP.NET WebAPI Security 2: Identity Architecture

    - by Your DisplayName here!
    Pedro has beaten me to the punch with a detailed post (and diagram) about the WebAPI hosting architecture. So go read his post first, then come back so we can have a closer look at what that means for security. The first important takeaway is that WebAPI is hosting independent-  currently it ships with two host integration implementations – one for ASP.NET (aka web host) and WCF (aka self host). Pedro nicely shows the integration into the web host. Self hosting is not done yet so we will mainly focus on the web hosting case and I will point out security related differences when they exist. The interesting part for security (amongst other things of course) is the HttpControllerHandler (see Pedro’s diagram) – this is where the host specific representation of an HTTP request gets converted to the WebAPI abstraction (called HttpRequestMessage). The ConvertRequest method does the following: Create a new HttpRequestMessage. Copy URI, method and headers from the HttpContext. Copies HttpContext.User to the Properties<string, object> dictionary on the HttpRequestMessage. The key used for that can be found on HttpPropertyKeys.UserPrincipalKey (which resolves to “MS_UserPrincipal”). So the consequence is that WebAPI receives whatever IPrincipal has been set by the ASP.NET pipeline (in the web hosting case). Common questions are: Are there situations where is property does not get set? Not in ASP.NET – the DefaultAuthenticationModule in the HTTP pipeline makes sure HttpContext.User (and Thread.CurrentPrincipal – more on that later) are always set. Either to some authenticated user – or to an anonymous principal. This may be different in other hosting environments (again more on that later). Why so generic? Keep in mind that WebAPI is hosting independent and may run on a host that materializes identity completely different compared to ASP.NET (or .NET in general). This gives them a way to evolve the system in the future. How does WebAPI code retrieve the current client identity? HttpRequestMessage has an extension method called GetUserPrincipal() which returns the property as an IPrincipal. A quick look at self hosting shows that the moral equivalent of HttpControllerHandler.ConvertRequest() is HttpSelfHostServer.ProcessRequestContext(). Here the principal property gets only set when the host is configured for Windows authentication (inconsisteny). Do I like that? Well – yes and no. Here are my thoughts: I like that it is very straightforward to let WebAPI inherit the client identity context of the host. This might not always be what you want – think of an ASP.NET app that consists of UI and APIs – the UI might use Forms authentication, the APIs token based authentication. So it would be good if the two parts would live in a separate security world. It makes total sense to have this generic hand off point for identity between the host and WebAPI. It also makes total sense for WebAPI plumbing code (especially handlers) to use the WebAPI specific identity abstraction. But – c’mon we are running on .NET. And the way .NET represents identity is via IPrincipal/IIdentity. That’s what every .NET developer on this planet is used to. So I would like to see a User property of type IPrincipal on ApiController. I don’t like the fact that Thread.CurrentPrincipal is not populated. T.CP is a well established pattern as a one stop shop to retrieve client identity on .NET.  That makes a lot of sense – even if the name is misleading at best. There might be existing library code you want to call from WebAPI that makes use of T.CP (e.g. PrincipalPermission, or a simple .Name or .IsInRole()). Having the client identity as an ambient property is useful for code that does not have access to the current HTTP request (for calling GetUserPrincipal()). I don’t like the fact that that the client identity conversion from host to WebAPI is inconsistent. This makes writing security plumbing code harder. I think the logic should always be: If the host has a client identity representation, copy it. If not, set an anonymous principal on the request message. Btw – please don’t annoy me with the “but T.CP is static, and static is bad for testing” chant. T.CP is a getter/setter and, in fact I find it beneficial to be able to set different security contexts in unit tests before calling in some logic. And, in case you have wondered – T.CP is indeed thread static (and the name comes from a time where a logical operation was bound to a thread – which is not true anymore). But all thread creation APIs in .NET actually copy T.CP to the new thread they create. This is the case since .NET 2.0 and is certainly an improvement compared to how Win32 does things. So to sum it up: The host plumbing copies the host client identity to WebAPI (this is not perfect yet, but will surely be improved). or in other words: The current WebAPI bits don’t ship with any authentication plumbing, but solely use whatever authentication (and thus client identity) is set up by the host. WebAPI developers can retrieve the client identity from the HttpRequestMessage. Hopefully my proposed changes around T.CP and the User property on ApiController will be added. In the next post, I will detail how to add WebAPI specific authentication support, e.g. for Basic Authentication and tokens. This includes integrating the notion of claims based identity. After that we will look at the built-in authorization bits and how to improve them as well. Stay tuned.

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 3: ADFS Setup

    - by Your DisplayName here!
    In part 1 of this series I briefly gave an overview of the ADFS / WS-Trust infrastructure. In part 2 we created a basic WCF service that uses ADFS for authentication. This part will walk you through the steps to register the service in ADFS 2. I could provide screenshots for all the wizard pages here – but since this is really easy – I just go through the necessary steps in textual form. Step 1 – Select Data Source Here you can decide if you want to import a federation metadata file that describes the service you want to register. In that case all necessary information is inside the metadata document and you are done. FedUtil (a tool that ships with WIF) can generate such metadata for the most simple cases. Another tool to create metadata can be found here. We choose ‘Manual’ here. Step 2 – Specify Display Name I guess that’s self explaining. Step 3 – Choose Profile Choose ‘ADFS 2 Profile’ here. Step 4 – Configure Certificate Remember that we specified a certificate (or rather a private key) to be used to decrypting incoming tokens in the previous post. Here you specify the corresponding public key that ADFS 2 should use for encrypting the token. Step 5 – Configure URL This page is used to configure WS-Federation and SAML 2.0p support. Since we are using WS-Trust you can leave both boxes unchecked. Step 6 – Configure Identifier Here you specify the identifier (aka the realm, aka the appliesTo) that will be used to request tokens for the service. This value will be used in the token request and is used by ADFS 2 to make a connection to the relying party configuration and claim rules. Step 7 – Configure Issuance Authorization Rules Here you can configure who is allowed to request token for the service. I won’t go into details here how these rules exactly work – that’s for a separate blog post. For now simply use the “Permit all users” option. OK – that’s it. The service is now registered at ADFS 2. In the next part we will finally look at the service client. Stay tuned…

    Read the article

  • Thinktecture.IdentityModel: WRAP and SWT Support

    - by Your DisplayName here!
    The latest drop of Thinktecture.IdentityModel contains some helpers for the Web Resource Authorization Protocol (WRAP) and Simple Web Tokens (SWT). WRAP The WrapClient class is a helper to request SWT tokens via WRAP. It supports issuer/key, SWT and SAML input credentials, e.g.: var client = new WrapClient(wrapEp); var swt = client.Issue(issuerName, issuerKey, scope); All Issue overrides return a SimpleWebToken type, which brings me to the next helper class. SWT The SimpleWebToken class wraps a SWT token. It combines a number of features: conversion between string format and CLR type representation creation of SWT tokens validation of SWT token projection of SWT token as IClaimsIdentity helpers to embed SWT token in headers and query strings The following sample code generates a SWT token using the helper class: private static string CreateSwtToken() {     var signingKey = "wA…";     var audience = "http://websample";     var issuer = "http://self";       var token = new SimpleWebToken(       issuer, audience, Convert.FromBase64String(signingKey));     token.AddClaim(ClaimTypes.Name, "dominick");     token.AddClaim(ClaimTypes.Role, "Users");     token.AddClaim(ClaimTypes.Role, "Administrators");     token.AddClaim("simple", "test");       return token.ToString(); }

    Read the article

  • Updated IdentityServer Sample Relying Party

    - by Your DisplayName here!
    I just uploaded a new version of the sample relying party. The three changes are: Added a session token diagnostics page. This allows to look at cookie sizes, details and the raw contents Sample code to switch to session mode Sample code to implement sliding expiration This was already included since 1.0: WS-Federation example Claims viewer Token viewer Active sign in via WS-Trust Delegation HTH

    Read the article

  • Token based Authentication for WCF HTTP/REST Services: Authentication

    - by Your DisplayName here!
    This post shows some of the implementation techniques for adding token and claims based security to HTTP/REST services written with WCF. For the theoretical background, see my previous post. Disclaimer The framework I am using/building here is not the only possible approach to tackle the problem. Based on customer feedback and requirements the code has gone through several iterations to a point where we think it is ready to handle most of the situations. Goals and requirements The framework should be able to handle typical scenarios like username/password based authentication, as well as token based authentication The framework should allow adding new supported token types Should work with WCF web programming model either self-host or IIS hosted Service code can rely on an IClaimsPrincipal on Thread.CurrentPrincipal that describes the client using claims-based identity Implementation overview In WCF the main extensibility point for this kind of security work is the ServiceAuthorizationManager. It gets invoked early enough in the pipeline, has access to the HTTP protocol details of the incoming request and can set Thread.CurrentPrincipal. The job of the SAM is simple: Check the Authorization header of the incoming HTTP request Check if a “registered” token (more on that later) is present If yes, validate the token using a security token handler, create the claims principal (including claims transformation) and set Thread.CurrentPrincipal If no, set an anonymous principal on Thread.CurrentPrincipal. By default, anonymous principals are denied access – so the request ends here with a 401 (more on that later). To wire up the custom authorization manager you need a custom service host – which in turn needs a custom service host factory. The full object model looks like this: Token handling A nice piece of existing WIF infrastructure are security token handlers. Their job is to serialize a received security token into a CLR representation, validate the token and turn the token into claims. The way this works with WS-Security based services is that WIF passes the name/namespace of the incoming token to WIF’s security token handler collection. This in turn finds out which token handler can deal with the token and returns the right instances. For HTTP based services we can do something very similar. The scheme on the Authorization header gives the service a hint how to deal with an incoming token. So the only missing link is a way to associate a token handler (or multiple token handlers) with a scheme and we are (almost) done. WIF already includes token handler for a variety of tokens like username/password or SAML 1.1/2.0. The accompanying sample has a implementation for a Simple Web Token (SWT) token handler, and as soon as JSON Web Token are ready, simply adding a corresponding token handler will add support for this token type, too. All supported schemes/token types are organized in a WebSecurityTokenHandlerCollectionManager and passed into the host factory/host/authorization manager. Adding support for basic authentication against a membership provider would e.g. look like this (in global.asax): var manager = new WebSecurityTokenHandlerCollectionManager(); manager.AddBasicAuthenticationHandler((username, password) => Membership.ValidateUser(username, password));   Adding support for Simple Web Tokens with a scheme of Bearer (the current OAuth2 scheme) requires passing in a issuer, audience and signature verification key: manager.AddSimpleWebTokenHandler(     "Bearer",     "http://identityserver.thinktecture.com/trust/initial",     "https://roadie/webservicesecurity/rest/",     "WFD7i8XRHsrUPEdwSisdHoHy08W3lM16Bk6SCT8ht6A="); In some situations, SAML token may be used as well. The following configures SAML support for a token coming from ADFS2: var registry = new ConfigurationBasedIssuerNameRegistry(); registry.AddTrustedIssuer( "d1 c5 b1 25 97 d0 36 94 65 1c e2 64 fe 48 06 01 35 f7 bd db", "ADFS"); var adfsConfig = new SecurityTokenHandlerConfiguration(); adfsConfig.AudienceRestriction.AllowedAudienceUris.Add( new Uri("https://roadie/webservicesecurity/rest/")); adfsConfig.IssuerNameRegistry = registry; adfsConfig.CertificateValidator = X509CertificateValidator.None; // token decryption (read from config) adfsConfig.ServiceTokenResolver = IdentityModelConfiguration.ServiceConfiguration.CreateAggregateTokenResolver();             manager.AddSaml11SecurityTokenHandler("SAML", adfsConfig);   Transformation The custom authorization manager will also try to invoke a configured claims authentication manager. This means that the standard WIF claims transformation logic can be used here as well. And even better, can be also shared with e.g. a “surrounding” web application. Error handling A WCF error handler takes care of turning “access denied” faults into 401 status codes and a message inspector adds the registered authentication schemes to the outgoing WWW-Authenticate header when a 401 occurs. The next post will conclude with authorization as well as the source code download.   (Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)

    Read the article

  • Access Control Service: Protocol and Token Transition

    - by Your DisplayName here!
    ACS v2 supports a number of protocols (WS-Federation, WS-Trust, OpenId, OAuth 2 / WRAP) and a number of token types (SWT, SAML 1.1/2.0) – see Vittorio’s Infographic here. Some protocols are designed for active client (WS-Trust, OAuth / WRAP) and some are designed for passive clients (WS-Federation, OpenID). One of the most obvious advantages of ACS is that it allows to transition between various protocols and token types. Once example would be using WS-Federation/SAML between your application and ACS to sign in with a Google account. Google is using OpenId and non-SAML tokens, but ACS transitions into WS-Federation and sends back a SAML token. This way you application only needs to understand a single protocol whereas ACS acts as a protocol bridge (see my ACS2 sample here). Another example would be transformation of a SAML token to a SWT. This is achieved by using the WRAP endpoint – you send a SAML token (from a registered identity provider) to ACS, and ACS turns it into a SWT token for the requested relying party, e.g. (using the WrapClient from Thinktecture.IdentityModel): [TestMethod] public void GetClaimsSamlToSwt() {     // get saml token from idp     var samlToken = Helper.GetSamlIdentityTokenForAcs();     // send to ACS for SWT converion     var swtToken = Helper.GetSimpleWebToken(samlToken);     var client = new HttpClient(Constants.BaseUri);     client.SetAccessToken(swtToken, WebClientTokenSchemes.OAuth);     // call REST service with SWT     var response = client.Get("wcf/client");     Assert.AreEqual<HttpStatusCode>(HttpStatusCode.OK, response.StatusCode); } There are more protocol transitions possible – but they are not so obvious. A popular example would be how to call a REST/SOAP service using e.g. a LiveId login. In the next post I will show you how to approach that scenario.

    Read the article

  • Thinktecture.IdentityServer Beta 1

    - by Your DisplayName here!
    I just upload beta 1 to codeplex. Please test this version and give me feedback. Some quick notes on setup Watch the intro screencast on the codeplex site. Use the setup tool to set the signing and SSL certificate. You can now also set the ACLs on the private key for your worker pool account. IIS is required . SSL for the IIS site the STS runs in is required. Users of the STS must be in the 'IdentityServerUsers' role. Admins of the STS must be in the 'IdentityServerAdministrators' roles. What’s new? Mainly smaller bits and pieces and some refactoring. The biggest under the cover change is a new authorization model for the STS itself. If, e.g. you don’t like the new roles I introduced, you can easily change the behavior in the claims authorization manager in the STS web site project. What’s missing? The big one is Azure support. Not that I ran into unforeseeable problems here, I just wanted to wait until the on-premise version is more stabilized. Now with B1 I can start adding Azure support back.

    Read the article

  • Thinktecture.IdentityServer RC

    - by Your DisplayName here!
    I just uploaded the RC of IdentityServer to Codeplex. This release is feature complete and if I don’t get any bug reports this is also pretty much the final V1. Changes from B1 The configuration data access is now based on EF 4.1 code first. This makes it much easier to use different data stores. For RTM I will also provide a SQL script for SQL Server so you can move the configuration to a separate machine (e.g. for load balancing scenarios). I included the ASP.NET Universal Providers in the download. This adds official support for SQL Azure, SQL Server and SQL Compact for the membership, roles and profile features. Unfortunately the Universal Provider use a different schema than the original ASP.NET providers (that sucks btw!) – so I made them optional. If you want to use them go to web.config and uncomment the new provider. The relying party registration entries now have added fields to add extra data that you want to couple with the RP. One use case could be to give the UI a hint how the login experience should look like per RP. This allows to have a different look and feel for different relying parties. I also included a small helper API that you can use to retrieve the RP record based on the incoming WS-Federation query string. WS-Federation single sign out is now conforming to the spec. Certificate based endpoint identities for SSL endpoints are optional now. Added a initial configuration “wizard”. This sets up the signing certificate, issuer URI and site title on the first run. Installation This is still a “developer” release – that means it ships with source code that you have to build it etc. But from that point it should be a little more straightforward as it used to be: Make sure SSL is configured correctly for IIS Map the WebSite directory to a vdir in IIS Run the web site. This should bring up the initial configuration Make sure the worker process account has access to the signing certificate private key Make sure all your users are in the “IdentityServerUsers” role in your role store. Administrators need the “IdentityServerAdministrators” role That should be it. A proper documentation will be hopefully available soon (any volunteers?). Please provide feedback! thanks!

    Read the article

  • Identity in .NET 4.5&ndash;Part 1: Status Quo (Beta 1)

    - by Your DisplayName here!
    .NET 4.5 is a big release for claims-based identity. WIF becomes part of the base class library and structural classes like Claim, ClaimsPrincipal and ClaimsIdentity even go straight into mscorlib. You will be able to access all WIF functionality now from prominent namespaces like ‘System.Security.Claims’ and ‘System.IdentityModel’ (yay!). But it is more than simply merging assemblies; in fact claims are now a first class citizen in the whole .NET Framework. All built-in identity classes, like FormsIdentity for ASP.NET and WindowsIdentity now derive from ClaimsIdentity. Likewise all built-in principal classes like GenericPrincipal and WindowsPrincipal derive from ClaimsPrincipal. In other words, the moment you compile your .NET application against 4.5,  you are claims-based. That’s a big (and excellent) change.   While the classes are designed in a way that you won’t “feel” a difference by default, having the power of claims under the hood (and by default) will change the way how to design security features with the new .NET framework. I am currently doing a number of proof of concepts and will write about that in the future. There are a number of nice “little” features, like FindAll(), FindFirst(), HasClaim() methods on both ClaimsIdentity and ClaimsPrincipal. This makes querying claims much more streamlined. I also had to smile when I saw ClaimsPrincipal.Current (have a look at the code yourself) ;) With all the goodness also comes a number of breaking changes. I will write about that, too. In addition Vittorio announced just today the beta availability of a new wizard/configuration tool that makes it easier to do common things like federating with an IdP or creating a test STS. Go get the Beta and the tools and start writing claims-enabled applications! Interesting times ahead!

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 1

    - by Your DisplayName here!
    As mentioned in my last post, I made several additions to WIF’s built-in authorization infrastructure to make it more flexible and easy to use. The foundation for all this work is that you have to be able to directly call the registered ClaimsAuthorizationManager. The following snippet is the universal way to get to the WIF configuration that is currently in effect: public static ServiceConfiguration ServiceConfiguration {     get     {         if (OperationContext.Current == null)         {             // no WCF             return FederatedAuthentication.ServiceConfiguration;         }         // search message property         if (OperationContext.Current.IncomingMessageProperties. ContainsKey("ServiceConfiguration"))         {             var configuration = OperationContext.Current. IncomingMessageProperties["ServiceConfiguration"] as ServiceConfiguration;             if (configuration != null)             {                 return configuration;             }         }         // return configuration from configuration file         return new ServiceConfiguration();     } }   From here you can grab ServiceConfiguration.ClaimsAuthoriationManager which give you direct access to the CheckAccess method (and thus control over claim types and values). I then created the following wrapper methods: public static bool CheckAccess(string resource, string action) {     return CheckAccess(resource, action, Thread.CurrentPrincipal as IClaimsPrincipal); } public static bool CheckAccess(string resource, string action, IClaimsPrincipal principal) {     var context = new AuthorizationContext(principal, resource, action);     return AuthorizationManager.CheckAccess(context); } public static bool CheckAccess(Collection<Claim> actions, Collection<Claim> resources) {     return CheckAccess(new AuthorizationContext(         Thread.CurrentPrincipal.AsClaimsPrincipal(), resources, actions)); } public static bool CheckAccess(AuthorizationContext context) {     return AuthorizationManager.CheckAccess(context); } I also created the same set of methods but called DemandAccess. They internally use CheckAccess and will throw a SecurityException when false is returned. All the code is part of Thinktecture.IdentityModel on Codeplex – or via NuGet (Install-Package Thinktecture.IdentityModel).

    Read the article

  • WIF, ASP.NET 4.0 and Request Validation

    - by Your DisplayName here!
    Since the response of a WS-Federation sign-in request contains XML, the ASP.NET built-in request validation will trigger an exception. To solve this, request validation needs to be turned off for pages receiving such a response message. Starting with ASP.NET 4.0 you can plug in your own request validation logic. This allows letting WS-Federation messages through, while applying all standard request validation to all other requests. The WIF SDK (v4) contains a sample validator that does exactly that: public class WSFedRequestValidator : RequestValidator {     protected override bool IsValidRequestString(       HttpContext context,       string value,       RequestValidationSource requestValidationSource,       string collectionKey,       out int validationFailureIndex)     {         validationFailureIndex = 0;         if ( requestValidationSource == RequestValidationSource.Form &&              collectionKey.Equals(                WSFederationConstants.Parameters.Result,                StringComparison.Ordinal ) )         {             SignInResponseMessage message =               WSFederationMessage.CreateFromFormPost(context.Request)                as SignInResponseMessage;             if (message != null)             {                 return true;             }         }         return base.IsValidRequestString(           context,           value,           requestValidationSource,           collectionKey,           out validationFailureIndex );     } } Register this validator via web.config: <httpRuntime requestValidationType="WSFedRequestValidator" />

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >