Do we absolutely need a STS for SAML? - web-services

I am trying to implement SAML enabled SOAP services for the first time and I have some conceptual questions regarding the role of a Secure Token Service (STS) in a SAML implementation.
User ---> Web Application ---SOAP/SAML--> Messaging Application
Basically the scenario is that the user logs into the Web application using his user name and password, web application in turn authenticate and authorize the user with an external service, on successful authentication/authorization, Web application creates a Sender Vouches SAML assertion with user as subject, signs the assertion with its private key, packages the assertion in a soap envelope using WS-S and makes a SOAP call to the messaging application. Once messaging application receive the request, it verifies the signature with the public key of the web application, pull the authentication and attribute statements out of the SAML assertion and based on them enforce auth policy on the end point.
As you can see in the above scenario there was no external STS involved however most literature I have read on SAML suggest that an STS is absolutely required. The question I have is that am I doing anything wrong with the above scenario since I cannot see any reason why I would absolutely need an STS. Sure it would be nice to have a STS but at least in my opinion, absence of it does not stop me from implementing SAML for my use case.

No, you don't need an STS for SAML tokens in web services. The STS exchanges one token (where 'token' includes things like username+password) for another, so it's useful in that your web service consumer can send some input token (typically username+password or a signature+X.509 cert for simple use cases) to the STS and get back a SAML assertion all ready to go.
Now, if you have the capability to create SAML tokens that will be accepted by your web service provider, have at it! No STS necessary - the actual SOAP message on the wire is identical whether or not an STS was involved in its creation.
I wrote a couple of blog entries a few years ago that detail some of this:
Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack
Anatomy of a SAML-Secured SOAP Message
Sun Access Manager 7.1 has been superseded by OpenAM, but the principles remain the same. In particular, the second entry is independent of any actual product.

You can leverage any of the open source SAML toolkits. If your application is written in Java and you are running on either JBoss or Weblogic, SAML support is built-in.

Related

Using WSO2 API Manager with Identity Server and SEPARATE Identity Server Key Manager

We're in the process of configuring our suite of WSO2 products in a development environment and we're having a hard time wrapping our heads around IS Key Manager.
What we're going for is an Identity Server (already configured) with an OAuth Service Provider that an external web page can log into. This is already complete, we can get our token through IS just fine.
We now want to take the same token, and pass it to API Manager, and have API Manager understand the token, and the roles within, and approve or deny the API request.
Further in, we want to pass the token to Enterprise Integrator (which API Manager calls) and get info from the token (user info, claims) within a sequence.
IS is configured and working in it's isolated way (tokens generated from it aren't being accepted by APIM). APIM is configured in that it is pointing to an EI API.
EI is only configured in that it has an API with sequences that do stuff.
I've read through these:
https://docs.wso2.com/display/AM260/Key+Concepts#KeyConcepts-KeyManager
https://docs.wso2.com/display/AM210/Configuring+WSO2+Identity+Server+as+a+Key+Manager
They suggest a separate Key Manager that all can speak to. Makes sense. But the Key Manager when downloaded is an APIM instance? And looking deeper into the documentation it seems like this Key Manager is meant to REPLACE the traditional Identity Server, which doesn't support our use case (we need a separate Identity Server that can federate freely with others).
I assume I'm not understanding something about the Key Manager configuration properly.
In short:
IS needs to have an OAuth service provider to login to. Once the token is generated there, it will be sent to an APIM endpoint. APIM should understand the roles, and authorize it through. EI should then receive the token from APIM and then also understand the roles and authorize it through.
How can I accomplish this?
I would assume you got to the page where "API Manager" download page. Then you got the download pack named "wso2am-2.6.0.zip"?
There is a link on the same download page under "Other Resources" -> "Identity Server as a Key Manager Pack". You can get the "wso2is-km-5.7.0.zip".
This is almost same as "wso2is-5.7.0.zip", except very few config modification. You could use almost all the IS features in the same way.

Bluemix, SSO: Calling REST service from mobile app (public client, native application)

I have a Bluemix web application (Liberty for Java), which implements some web services. These web services should be called from a mobile application (Android). I have now secured this web application by binding it to the Bluemix Single Sign On service (SSO) with a cloud directory created in the SSO service. Using the web app from a web browser works fine; but, I have problems obtaining an access token from the SSO service, which would allow the mobile application to invoke the services.
From the OAuth2 specification (IETF RFC 6749), I figured that the appropriate way of doing this would be the "native application" profile with a "public client" (as specified in Clause 2.1 of the OAuth2 Spec) using the "password" grant type (OAuth2 spec, Clause 4.3 "Resource Owner Password Credentials Grant").
I used the Spring for Android framework for this purpose, and code for this would look like this:
ResourceOwnerPasswordResourceDetails resourceDetails =
new ResourceOwnerPasswordResourceDetails();
resourceDetails.setId("dtu-se2-e15-cloud-directory");
resourceDetails.setAccessTokenUri(APP_SSO_API_ACCESS_TOKEN_URI);
resourceDetails.setClientId(APP_SSO_API_CLIENT_ID);
resourceDetails.setClientSecret(APP_SSO_API_CLIENT_SECRET);
resourceDetails.setGrantType("password");
resourceDetails.setScope(Arrays.asList(SCOPE));
resourceDetails.setUsername(USERNAME);
resourceDetails.setPassword(PASSWORD);
OAuth2RestTemplate restTemplate = new OAuth2RestTemplate(resourceDetails);
restTemplate.getMessageConverters().add(new MappingJackson2HttpMessageConverter());
UserPosition newPosition = restTemplate.postForObject(
POST_POSITION_SERVICE_URI, position, UserPosition.class);
But, I don't think that this code matters, and ultimately made my experiments with obtaining access tokens directly with curl:
Actually, I tried using two different clients with different OAuth2 token endpoints:
I created a client (and client credentials) in the Cloud directory, that I had created in the Bluemix SSO service. And I tried the OAuth2 Token Endpoint URI and the created client credentials. But it appears that this endpoint does not support the grant type "password" at all. It appears that this client is not considered a public client by the endpoint.
I also tried the credentials and OAuth Token Endpoint URI for the Web application itself (which I looked up in the VCAP_SERVICES environment variable). This end point seems to support the grant type "password"; but all variants of requests I could think of, kept responding: invalid_resource_owner_credential.
As I said, I used curl to try out many different variations of requests to these
token endpoints:
used the token endpoint URI of both the SSO services with the web app credentials
as well as the one created in the cloud directory API Access
tried GET and POST (did not make any difference)
tried Content-Type: application/x-www-form-urlencoded and
Content-Type: application/json (both of them seemed to work with the same effect)
providing the client_id only (which always was unsuccessful)
providing the client credentials in the body or parameters, as well as
authenication information in the header (actually, I do not like the idea
of providing the client secret to the Android app, but I tried that too);
as user name, I tried the name as I had created it in the web browser redirection
when registering a new user; but I also tried the user name which the Principal of
the security context of a request would provide (when successfully invoking
a service from a web browser with the user logged in); I even tried the principal's
accessId (non of these worked, I always got: invalid_resource_owner_credential)
used different scopes, and none at all
None of the above (and different combinations of that) would result in a successful
response and an access token for the user. The "best" I could get was a response
invalid_resource_owner_credential (making me believe that at least the client was
accepted in some situations).
Unfortunately, I did not find many things that could be configured concerning client
access (and public clients, in particular), and I did not find much documentation on
which subset of the OAuth2 protocol (grant types and profiles) is supported by the
Bluemix SSO service and the attached cloud directory.
Can anyone could tell me how to authenticate with a Bluemix web application
(Liberty for Java) from a mobile app (Android) as a public client or how to set
up the Bluemix web app and the SSO service to which it is bound so that this is
possible. In case it would matter, I am working with Bluemix in the "US South"
region and under an IBM Academic Initiative membership account for Bluemix.
I would prefer a solution, where the mobile app would not need to know the client
secret, but if this is the only way to make this work for now, adding the client
credentials to the mobile app would be OK.
I would appreciate any help with this problem, thanks in advance,
Ekkart
Bluemix has a mobile-specific service called Mobile Client Access that could help to facilitate security for your mobile app. To read about it, log into Bluemix and look for it under the Mobile category. To ask questions about it here, use or search using the [bluemix-mobile-services] tag.

Best way to Integrate ADFS 2.0 authentication in a Django application

I need to use Active Directory Federation Services (ADFS) authentication in a Django application. I will create an authentication backend, but which tool would someone recommend me to make it as fast as possible, or would it be better to implement authentication from scratch?
I have read some articles from the Microsoft website, and have checked:
http://claimsid.codeplex.com/
http://msdn.microsoft.com/en-us/library/ff359102.aspx
But even though they explain some core concepts and ideas about ADFS and SSO, the examples are in my opinion more .NET stack focused.
Writing a basic client in .NET and sniffing the traffic would give you all necessary clues to actually implement the flow in any technology.
Basically, your django app has an endpoint adfs uses to return back. You register the endpoint in adfs (like https://myapp.com/authgateway).
Then, your application initializes the flow by redirecting to https://adfs.address/adfs/ls?wa=wsignin1.0&wtrealm=https://myapp.com/authgateway
Adfs picks the request and validates credentials. Then it creates a SAML token and redirects back to your application with a POST request containing the token.
Then comes the difficult part, the SAML token is a plain xml you can use to establish a local user session. One of the claims contains user name provided by adfs, other claims can contain roles, the email, whatever you configure at the adfs side.
But, to prevent forging, you need to validate the token. The validation consist in checking the XMLdsig signature and verifying that the signing certificate thumbprint matches the thumbprint of the adfs signing certificate. Depending on how much knowledge on x509 certificates and xml validation you have this can be easy or difficult. Try to find any support in django community.
Anyway, as you can see the basic flow is simple, is a matter of two redirects, a 302 from your application to adfs and a POST back from adfs to your application. Although we do this daily in .net, our partners do it in php/java under our guidance.
There's a package available for this here:
http://django-auth-adfs.readthedocs.org/en/latest/

OpenSSO SSOToken to SAML assertion and back

I'm considering securing a whole Java EE software platform with OpenAM (prev. Sun OpenSSO). Applications - running on WebLogic AS - would be secured by a JEE Policy Agent and web services with WS-Security SAML Token Profile.
As of my understanding, the SSOTokenManager enables application code to retrieve OpenAM's SSO token. But in order to invoke the SAML protected Web Services, I need to obtain a SAML Assertion from OpenAM. Can anybody tell me how to do so ?
Also, in the Web Service code, I may need to get back a SSO Token from a SAML assertion. Is that possible ?
You should be able to achieve both conversions using OpenSSO's Security Token Service. There is a tutorial for configuring it.
The SSOToken is an internal OpenAM representation of a users session, whilst a SAML token is an asserted identity with associated information. As such, these are not directly translatable in the way you describe.
In order to obtain a SAML token for use in your web service call, you should look at the STS functionality in OpenAM. The is a standardised service that will authenticate users and then make an assertion about the identity and authentication of the user, represented by a SAML token. This token is then returned to the calling entity (the web service client) who can include this token as per the relevant WS-* standards.
You may also want to look at the OpenAM wss provider or the Metro/WSIT library to assist implementation on the client side.

WSO2 Identity Server: Cannot use custom claims with OAuth2

We've Installed Pre-Packaged Identity Server 5.1.0 with API Manager 1.10.0 and use sqlserver as a data store.
We use OAUTH2 to authorize our API's and we want to map our local claims to a service provider (an application?). Behind the API we have a .Net Wcf Service with some logging where we read the header with WebOperationContext.Current.IncomingRequest.Headers["assertion"] and print the claims which are present.
The Claims which are returned are:
{"iss":"wso2.org/products/am"
"exp":1462357259751
"wso2url/claims/subscriber":"Sjaak"
"wso2url/claims/applicationid":"1003"
"wso2url/claims/applicationname":"DefaultApplication"
"wso2url/claims/applicationtier":"Medium"
"wso2url/claims/apicontext":"/Test/v1.0"
"wso2url/claims/version":"v1.0"
"wso2url/claims/tier":"Silver"
"wso2url/claims/keytype":"PRODUCTION"
"wso2url/claims/usertype":"APPLICATION"
"wso2url/claims/enduser":"Sjaak#carbon.super"
"wso2url/claims/enduserTenantId":"-1234"
"wso2url/claims/emailaddress":"sjakie#chocola.nl"
"wso2url/claims/givenname":"Sjakie"
"wso2url/claims/lastname":"van de Chocoladefabriek"
"wso2url/claims/role":"Internal/subscriber
Internal/everyone
Application/Sjaak_DefaultApplication_PRODUCTION"}
Where wso2url is http://wso2.org, but we cannot post this, because I don't have 10 reputation points...:(
The information in these claims is good, but only we want to use our own uri, so not wso2.org, but myorg.com. And we want to add other claims, with for example our own userId and some other stuff.
Among other things we have followed the guide for configuring claims for a service provider but had no success with this. We have made the assumption that an application is a service provider for which we can use the claims.
Has anyone got an idea what we are doing wrong? What do we need to do to add custom claims?
Thanks in advance!
[Added on 9th may]
Maybe this can point us in the right direction?
When we add a subscription to an application and we generate a new key than there is no new Service provider in the list:
The list of service provider without a new one for user Sjaak, so there is missing: Sjaak_CalculatorApp_PRODUCTION
But even when we do this for user admin the claims are not coming through. We have the following claim configuration and in my logging still the same claims as described above are there, no new ones, so no claim named accountnaam and no voogd.com uri:
Service Provider(SP) - It provides services to some end users and relies on a trusted Identity provider(IDP) to handle authentication and authorization for them. SP may use multiple protocols(Oauth2, SAML2, etc.) to communicate with IDP.
Claims are defined for SP, since same claims can be send over different protocols. In the default case, Identity server uses wso2 claim dialect(start with wos2.com) for claims. If you want a different claim dialect than this, use "Define Custom Claim Dialect" option in the service provider configuration. In there you can map wso2 claims(Local Claim) to your own claims(Service Provider Claim).