A few weeks ago, I said that I was sure that there was some way to get custom attributes passed in and out of SAML Assertions for the purpose of Federated Authorization. Well, at that time I was under the impression that this would require the creation of custom identity asserter that would some how clevery extend the OOTB SAML Identity Asserter. This still seems doable, but it felt pretty invasive...inelegant...ok, let's be honest, a hack. But, once again the core security team has come through, even if I didn't know it at the time :)
The key is the weblogic.security.providers.saml package. WebLogic Server for some time has had the concept of NameMappers. These are used by things like the DefaultIdentityAsserter to convert X.509 Subjects to username. Using the OOTB implementation of this interface, you can just choose and element from the DN - like email address. By implementing your own, you can get full access to the X.509 certificate and use things like SubjectAlternateName. The SAMLProviders have taken the NameMapper concept to whole new level.
In the weblogic.security.saml.providers package there are 4 name mappers. The SAMLCredentialNameMapper is used by the CredentialMapper to convert the current Subject to a SAML NameMapperInfo. A SAMLNameMapperInfo is really just a container for the username and optionally their groups. There is a corresponding name mapper for the SAML IdentityAsserter that converts the information found in the SAMLAssertion to users and groups. So, 2 of the 4 name mappers are really "meat and potatoes" NameMapper - one used in-bound (SAMLIdentityAssertionNameMapper) and one used out-bound (SAMLCrdentialNameMapper).
The remaining two NameMappers are the juicy ones. These two - the SAMLCredentialAttributeMapper and the SAMLIdentityAssertionAttributeMapper can be used to handle the attributes of the SAMLAssertion. As people will recall, this is the key to the Federated Authorization with OSB - the ability to produce and consume attributes for the purposes of authorization.
Looking at the SAMLIdentityAssertionAttributeMapper, there is just one method - mapAttributeInfo.
The interface provides full access the the attributes in the SAML Attribute Statements and expects that an implementation will map the AttributeStatements into Principals and add those back by placing them in a collection in the ContextElementDictionary.SAML_ATTRIBUTE_PRINCIPALS name in the ContextHandler. If the principals that are added implement the WLSGroup interface - the simplest is of course the WLSGroupImpl - then these principals will be picked-up as groups, and can be used very easily in either role or authorization policy.
Once again, the SSPI comes through...making it relatively simple to solve a rather complicated problem...I just wasn't sure how ;)
Saturday, June 27, 2009
Friday, June 5, 2009
WCF Interoperability with Java Kerberos - Tricky Problem - Simple Solution
File this one under hard lessons learned.
If you want to use WS-Security Kerberos Token Profile with a Java based client that is using Java GSS-API, then you have to use the HMAC-RC4 encryption type.
This means you'll needJDK 1.6
If you're setting this up the way that you've grown accustomed (setting the "Use DES Encyrption" flag in the user's Active Directory record), then you'll struggle - like I did.
Odd behvaior, like when you try requireDerivedKeys=false, you'll get errors like
Cannot create the 'http://www.w3.org/2001/04/xmlenc#tripledes-cbc
In fact, if the SPN is mapped to an account with DES Encryption, you'll only be able to get this to work with requireDerivedKeys=true. The algorithm in the binding doesn't matter.
Another error that you'll encounter is:
The key size requirements for the 'Basic128' algorithm suite are not met by the 'System.IdentityModel.Tokens.KerberosReceiverSecurityToken' token which has key size of '64'
I think what they're trying to say is that the DES key 64 bits is not sufficient to work with Basic128.
In my experience, simply changing the user account mapped to the SPN to Not use DES Encryption made all of these problems go away, and interoperability work like a charm.
If you want to use WS-Security Kerberos Token Profile with a Java based client that is using Java GSS-API, then you have to use the HMAC-RC4 encryption type.
This means you'll needJDK 1.6
If you're setting this up the way that you've grown accustomed (setting the "Use DES Encyrption" flag in the user's Active Directory record), then you'll struggle - like I did.
Odd behvaior, like when you try requireDerivedKeys=false, you'll get errors like
Cannot create the 'http://www.w3.org/2001/04/xmlenc#tripledes-cbc
In fact, if the SPN is mapped to an account with DES Encryption, you'll only be able to get this to work with requireDerivedKeys=true. The algorithm in the binding doesn't matter.
Another error that you'll encounter is:
The key size requirements for the 'Basic128' algorithm suite are not met by the 'System.IdentityModel.Tokens.KerberosReceiverSecurityToken' token which has key size of '64'
I think what they're trying to say is that the DES key 64 bits is not sufficient to work with Basic128.
In my experience, simply changing the user account mapped to the SPN to Not use DES Encryption made all of these problems go away, and interoperability work like a charm.
Wednesday, June 3, 2009
Does OSB 10gR3 Support OCSP and CRL checks?
Seems like a simple question, but like in most things security, the devil is in the details.
The use case here is that a SOAP request made over 2-way SSL is also signed and encrypted. Let's for the sake of maximum complexity, assume that the client certificate at the transport level is different than the signer of the SOAP message.
Can OSB make CRL and OCSP checks for both certificates to ensure the validity of the message?
WebLogic server has a little known security provider called a CertPath Provider. This security provider, like the other security providers, is configured as part of the realm and can be used to extend/configure the security behavior for WebLogic Server. The default CertPath Provider does a lot of thing to ensure the validity of certificates:
From WebLogic Server Documentation
Well, this is not exactly OCSP or CRL checking. Good, but not the same as those standards. Well wait, WebLogic has another OOTB CertPath provider - the CertificateRegistry. In this provider, you store the list of valid certificates - think of it as a Certificate Allowed List (CAL?). All of this can be managed via WebLogic Console. This is also good, and a workable solution for a small number of certificates, but not quite meeting the requirements.
So, looks like we need to create a custom CertPath provider. The really interesting think about this provider is that it also has to implement the java.security.cert.CertPathBuilderSpi
Really, all the WebLogic CertPath provider is a wrapper around the standard JDK interfaces.
So, the really good news is that starting inJDK 1.5 has built in support of CRL and OCSP checking through its default PKIX provider
This means that even though there is no OOTB OCSP and CRL checking in OSB/WLS OOTB, the custom CertPath provider is just a simple wrapper around an already existing JDK provided implementation.
Like most providers, at runtime the CertPath provider does get passed a ContextHandler - which in the case of an OSB Proxy Service - has all sorts of information about the request and the requestor in it. If you want to get really crazy, you could have different behaviors by resource - for example, different OCSP responders, or different trustedCAs and a per endpoint basis.
The other good news is that Web Services security uses the CertPath provider automatically to validate certificates. By default, SSL does not, but can be simply configured to do so by going to the Advanced tab of the SSL on the server, and set Inbound SSL Validation to Built In SSL Validation and CertPath Validators
The use case here is that a SOAP request made over 2-way SSL is also signed and encrypted. Let's for the sake of maximum complexity, assume that the client certificate at the transport level is different than the signer of the SOAP message.
Can OSB make CRL and OCSP checks for both certificates to ensure the validity of the message?
WebLogic server has a little known security provider called a CertPath Provider. This security provider, like the other security providers, is configured as part of the realm and can be used to extend/configure the security behavior for WebLogic Server. The default CertPath Provider does a lot of thing to ensure the validity of certificates:
From WebLogic Server Documentation
The WebLogic Server CertPath provider also checks the signatures in the chain, ensures that the chain has not expired, and checks that one of the certificates in the chain is issued by one of the trusted CAs configured for the server. If any of these checks fail, the chain is not valid. Finally, the provider checks each certificate’s basic constraints (that is, the ability of the certificate to issue other certificates) to ensure the certificate is in the proper place in the chain.
Well, this is not exactly OCSP or CRL checking. Good, but not the same as those standards. Well wait, WebLogic has another OOTB CertPath provider - the CertificateRegistry. In this provider, you store the list of valid certificates - think of it as a Certificate Allowed List (CAL?). All of this can be managed via WebLogic Console. This is also good, and a workable solution for a small number of certificates, but not quite meeting the requirements.
So, looks like we need to create a custom CertPath provider. The really interesting think about this provider is that it also has to implement the java.security.cert.CertPathBuilderSpi
Really, all the WebLogic CertPath provider is a wrapper around the standard JDK interfaces.
So, the really good news is that starting inJDK 1.5 has built in support of CRL and OCSP checking through its default PKIX provider
This means that even though there is no OOTB OCSP and CRL checking in OSB/WLS OOTB, the custom CertPath provider is just a simple wrapper around an already existing JDK provided implementation.
Like most providers, at runtime the CertPath provider does get passed a ContextHandler - which in the case of an OSB Proxy Service - has all sorts of information about the request and the requestor in it. If you want to get really crazy, you could have different behaviors by resource - for example, different OCSP responders, or different trustedCAs and a per endpoint basis.
The other good news is that Web Services security uses the CertPath provider automatically to validate certificates. By default, SSL does not, but can be simply configured to do so by going to the Advanced tab of the SSL on the server, and set Inbound SSL Validation to Built In SSL Validation and CertPath Validators
How to Debug SAML Token Profile on WLS
K asks:
So I think there are a couple of questions:
1 - Did you configure a SAML Identity Asserter?
2 - Did you configure an asserting that matches the client - same confirmation method, same audience, issuer uri?
NOTE: There is an issue in 10.3 that if you manually configure the partners through the console, the constants for the subject confirmation method written into the embedded LDAP are wrong. You'll need to use WLST to do this and get the constants correct. Correct in this case means to include the full uri of the subject confirmation method, not just the name "holder-of-key"
3 - Did you configure the server to have an identity? Either through setting up SSL or through a Domain Level Web Services configuration?
4 - Did you turn on WS-Security debugging?
5 - Did you turn on the weblogic SAML2, atn, and LDAP debug targets for the server?
The most common problem is that the partner configuration doesn't match.
On the client site I have two Credential Mapping Provider (SAML and PKI) and two Credential Mapping (Key Pair and certificate) configured and the request produced well (I monitor it with wireshark). But the server side returns with error (Caused by: javax.xml.rpc.JAXRPCException: weblogic.xml.crypto.wss.WSSecurityException: Could not validate encryption against any of the supported token types).
What should I configure on the server side? Is a single SAML 2.0 Identity Assertion Provider is enough? Should I configure an additional PKI mapping or anything else? Do you know some more detailed documentation about a similar Use Case?
So I think there are a couple of questions:
1 - Did you configure a SAML Identity Asserter?
2 - Did you configure an asserting that matches the client - same confirmation method, same audience, issuer uri?
NOTE: There is an issue in 10.3 that if you manually configure the partners through the console, the constants for the subject confirmation method written into the embedded LDAP are wrong. You'll need to use WLST to do this and get the constants correct. Correct in this case means to include the full uri of the subject confirmation method, not just the name "holder-of-key"
3 - Did you configure the server to have an identity? Either through setting up SSL or through a Domain Level Web Services configuration?
4 - Did you turn on WS-Security debugging?
5 - Did you turn on the weblogic SAML2, atn, and LDAP debug targets for the server?
The most common problem is that the partner configuration doesn't match.
Tuesday, June 2, 2009
SAML and OSB 10gR3 - Federated Authorization
I recently spent a lot of time with a customer on this use case, and it also appeared on the Oracle Forums, so I thought it would be worth posting some of the details.
The use case is basically processing a SAML assertion in Oracle Service Bus for the purpose of not only authentication, but authorization as well.
In most of these cases, the client first makes a call to an STS (Secure Token Service) and gets a SAML assertion that contains some claims. These claims could be SAML Authorization statements or attributes of the user's profile or actions that the user can perform on the service. Regardless, they show up at the OSB as Attribute Statements in the SAML Assertion.
The question for OSB, is how to process this information and use it for authorization?
In this post, I'll describe what can be done simply using OOTB capabilities. The SAML Identity Asserter is the component inside of OSB that processes the SAML Assertion. You can configure the SAML Identity Asserter to process the group attributes. What are the group attributes? WLS and therefore OSB has the ability to get groups for the user from a SAML Assertion.
So, a SAML Assertion like this:
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="de7790da1578ae713b9fbe9399a87e3d" IssueInstant="2009-05-27T23:54:44.219Z" Issuer="http://fedtest" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2009-05-27T23:54:44.219Z" NotOnOrAfter="2009-05-27T23:56:44.219Z"></Conditions><AuthenticationStatement AuthenticationInstant="2009-05-27T23:54:44.219Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">josh</NameIdentifier>
<SubjectConfirmation><ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></SubjectConfirmation></Subject>
<Attribute AttributeName="Groups"AttributeNamespace="urn:bea:security:saml:groups">
<AttributeValue>group1</AttributeValue><AttributeValue>group2</AttributeValue>
</Attribute></AttributeStatement></Assertion>
Then you'll wind-up with a Subject named josh who has two WLSGroup principals group1 and group2.
At this point, you just need to figure out how to use these groups in authorization. You could use the role mapper to map the groups to roles, and then assign those roles policies granting them access to OSB Proxy services. As an alternative, you could just skip roles, and grant access to the web-services to those groups directly.
The groups themselves don't have to exist in any directory. The values above of group1 and group2 could easily replaced with priv#trade or role#foo.
In fact the user doesn't have to exist either - its a virtual user. Since the SAML Assertion is valid, OSB will just trust what is in the assertion.
This is not the only federated authorization model that you can use with OSB, but hopefully this post shows what is simply there OOTB with OSB. There are obviously more elaborate scenarios like one-time-identifiers or more elaborate claims that would require some custom work. One of the strong points of OSB is that its built on top of WLS Security, and I've used that framework to solve a ton of use-cases. I'm sure there is a way through configuration and/or custom providers that these use cases could be met. If there's interest, I'd be happy to explore the specifics here.
The use case is basically processing a SAML assertion in Oracle Service Bus for the purpose of not only authentication, but authorization as well.
In most of these cases, the client first makes a call to an STS (Secure Token Service) and gets a SAML assertion that contains some claims. These claims could be SAML Authorization statements or attributes of the user's profile or actions that the user can perform on the service. Regardless, they show up at the OSB as Attribute Statements in the SAML Assertion.
The question for OSB, is how to process this information and use it for authorization?
In this post, I'll describe what can be done simply using OOTB capabilities. The SAML Identity Asserter is the component inside of OSB that processes the SAML Assertion. You can configure the SAML Identity Asserter to process the group attributes. What are the group attributes? WLS and therefore OSB has the ability to get groups for the user from a SAML Assertion.
So, a SAML Assertion like this:
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="de7790da1578ae713b9fbe9399a87e3d" IssueInstant="2009-05-27T23:54:44.219Z" Issuer="http://fedtest" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2009-05-27T23:54:44.219Z" NotOnOrAfter="2009-05-27T23:56:44.219Z"></Conditions><AuthenticationStatement AuthenticationInstant="2009-05-27T23:54:44.219Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">josh</NameIdentifier>
<SubjectConfirmation><ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></SubjectConfirmation></Subject>
<Attribute AttributeName="Groups"AttributeNamespace="urn:bea:security:saml:groups">
<AttributeValue>group1</AttributeValue><AttributeValue>group2</AttributeValue>
</Attribute></AttributeStatement></Assertion>
Then you'll wind-up with a Subject named josh who has two WLSGroup principals group1 and group2.
At this point, you just need to figure out how to use these groups in authorization. You could use the role mapper to map the groups to roles, and then assign those roles policies granting them access to OSB Proxy services. As an alternative, you could just skip roles, and grant access to the web-services to those groups directly.
The groups themselves don't have to exist in any directory. The values above of group1 and group2 could easily replaced with priv#trade or role#foo.
In fact the user doesn't have to exist either - its a virtual user. Since the SAML Assertion is valid, OSB will just trust what is in the assertion.
This is not the only federated authorization model that you can use with OSB, but hopefully this post shows what is simply there OOTB with OSB. There are obviously more elaborate scenarios like one-time-identifiers or more elaborate claims that would require some custom work. One of the strong points of OSB is that its built on top of WLS Security, and I've used that framework to solve a ton of use-cases. I'm sure there is a way through configuration and/or custom providers that these use cases could be met. If there's interest, I'd be happy to explore the specifics here.
Subscribe to:
Posts (Atom)
Posts
